[ANNOUNCE] GHC 8.4.3 released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] GHC 8.4.3 released

Ben Gamari-3
Hello everyone,

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

This release includes a few bug fixes including:

 * A code generation bug resulting in crashing of some programs using
   UnboxedSums has been fixed (#15038).

 * #14381, where Cabal and GHC would disagree about abi-depends,
   resulting in build failures, has been worked around. Note that the
   work-around patch has already been shipped by several distributions
   in previous releases, so this change may not be visible to you.

 * By popular demand, GHC now logs a message when it reads a package
   environment file, hopefully eliminating some of the confusion wrought
   by this feature.

 * GHC now emits assembler agreeable to newer versions of Gnu binutils,
   fixing #15068.

 * SmallArray#s can now be compacted into a compact region

Thanks to everyone who has contributed to developing, documenting, and
testing this release!

As always, let us know if you encounter trouble.


How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.


Background
~~~~~~~~~~

Haskell is a standardized lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell. Included is an
optimising compiler generating efficient code for a variety of platforms,
together with an interactive system for convenient, quick development. The
distribution includes space and time profiling facilities, a large collection of
libraries, and support for various language extensions, including concurrency,
exceptions, and foreign language interfaces. GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references, contact
information, links to research groups) are available from the Haskell home page
(see below).


On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs:

GHC home page              https://www.haskell.org/ghc/
GHC developers' home page  https://ghc.haskell.org/trac/ghc/
Haskell home page          https://www.haskell.org/


Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them, is here:

    https://ghc.haskell.org/trac/ghc/wiki/TeamGHC

Ports to other platforms are possible with varying degrees of difficulty. The
Building Guide describes how to go about porting to a new platform:

    https://ghc.haskell.org/trac/ghc/wiki/Building


Developers
~~~~~~~~~~

We welcome new contributors. Instructions on accessing our source code
repository, and getting started with hacking on GHC, are available from the
GHC's developer's site:

    https://ghc.haskell.org/trac/ghc/


Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use the web
interfaces at

    https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
    https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    https://mail.haskell.org/cgi-bin/mailman/listinfo

Many GHC developers hang out on #haskell on IRC:

    https://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here:

    https://www.haskell.org/ghc/reportabug



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Jens Petersen-4
On 30 May 2018 at 05:07, Ben Gamari <[hidden email]> wrote:
>     https://downloads.haskell.org/~ghc/8.4.3

Thanks!

I have built it for Fedora and EPEL 7 (RHEL/CentOS) in a Copr repo:

https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.3

Cheers, Jens
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Viktor Dukhovni
In reply to this post by Ben Gamari-3
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

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

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)
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

--
        Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Ben Gamari-2
Viktor Dukhovni <[hidden email]> 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


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Jannis Limperg
In reply to this post by Ben Gamari-3
Hej Ben,

the release page for GHC 8.4.3 is currently missing a Fedora binary. Is
this intentional?

(It would be nice to have this binary since afaict `stack setup` relies
on it for systems with ncurses6/tinfo8.)

Cheers,
Jannis
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Viktor Dukhovni
In reply to this post by Ben Gamari-2
On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:

> > 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.

For the record, in case anyone gets the wrong impression, I am not
one of the port maintainers (who deserve the credit for creating
the port).  I'm just a happy user of the port, which was upgraded
from 8.4.2 to 8.4.3 on Jun 30th.  No issues with either version on
FreeBSD 11.1-RELEASE-p10.

My meagre contribution amounts to reporting success with:

        # cd /usr/ports/lang/ghc
        # make config
        # make package
        # pkg install work/pkg/ghc-8.4.3.txz

The "make config" options include:

    BOOT     Use installed GHC for bootstrapping

which speeds up upgrade builds.

--
        Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: GHC FreeBSD memory model (was: 8.4.3 release)

Viktor Dukhovni
In reply to this post by Ben Gamari-2
On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:

> We use a much different memory allocation strategy on FreeBSD which
> (AFAIK) does not allow one to reserve address space without also
> committing.

Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
mappings to behave similarly on older systems.

    $ cat foo.c
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
        size_t heaplen = 1ULL << 40; /* 1TB */
        unsigned char *heap;

        heap = mmap(NULL, heaplen, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
        heap[0] = 'A';
        heap[heaplen-1] = 'z';
        printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
        sleep(2);
        return 0;
    }

    $ ./foo & sleep 1; ps -o vsz= -o rss= $! ; wait
    [1] 75193
    0x800e00000(1099511627776) A z
    1073750140 2076
    [1]+  Done                    ./foo

    $ printf "0x%8x\n" $(( 1073750140 * 1024 ))
    0x1000081f000

The process gets a contiguous 1TB of anonymous demand-paged zero-filled
memory, and a virtual size of 1TB + 0x81f000 bytes.   The resident
set size is a modest 2MB.

--
        Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: GHC FreeBSD memory model (was: 8.4.3 release)

Viktor Dukhovni
On Thu, Jul 05, 2018 at 08:13:33PM -0400, Viktor Dukhovni wrote:

> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
>
> > We use a much different memory allocation strategy on FreeBSD which
> > (AFAIK) does not allow one to reserve address space without also
> > committing.
>
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
>
>     $ cat foo.c
>     #include <stdio.h>
>     #include <stdlib.h>
>     #include <unistd.h>
>     #include <sys/mman.h>
>
>     int main(int argc, char **argv)
>     {
> size_t heaplen = 1ULL << 40; /* 1TB */
> unsigned char *heap;
>
> heap = mmap(NULL, heaplen, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
> heap[0] = 'A';
> heap[heaplen-1] = 'z';
> printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
> sleep(2);
> return 0;
>     }

I also get essentially the same results with posix_memalign(3):

    #include <stdlib.h>
    #include <stdio.h>
    #include <err.h>
    #include <unistd.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
        size_t heaplen = 1ULL << 40;
        void *p;
        unsigned char *heap;

        if (posix_memalign(&p, getpagesize(), heaplen) != 0)
            err(1, "posix_memalign");
        heap = p;
        heap[0] = 'A';
        heap[heaplen-1] = 'z';
        printf ("%p(%zd) %c %c\n", heap, heaplen, heap[0], heap[heaplen-1]);
        sleep(2);
        return 0;
    }

    $ ./foo & sleep 1; ps -o vsz= -o rss= $! ; wait
    [1] 76003
    0x801000000(1099511627776) A z
    1073750140 2080
    [1]+  Done                    ./foo

--
        Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: GHC FreeBSD memory model (was: 8.4.3 release)

Ben Gamari-3
In reply to this post by Viktor Dukhovni
Viktor Dukhovni <[hidden email]> writes:

> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
>
>> We use a much different memory allocation strategy on FreeBSD which
>> (AFAIK) does not allow one to reserve address space without also
>> committing.
>
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
>
Hmm, it's possible this could be fixed fairly easily in that case. The
original reason for disabling the two-step allocator is #12695, where
GHC failed to build due to MAP_NORESERVE being undefined. I had assumed
that this meant that reservation-only mappings weren't defined however
now that I look again at the mmap(2) manpage it looks like I
am probably wrong. MAP_NORESERVE merely flags to the system that swap
space should not be reserved for the mapping.

It looks like this functionality was simply never implemented in FreeBSD
and the flag eventually removed in [1]. However, your example suggests
that the kernel may be doing the right thing by default. It sounds to me
like we could likely remove the assertion enforcing the availability of
MAP_NORESERVE and enable two-step allocation on FreeBSD.

My only question is how one performs reservation-and-commit mappings on
FreeBSD. This is important since without committing any access to the
mapping may crash the program in the case of OOM. Does FreeBSD simply
not provide a way to safely map known-good memory?

Regardless, thanks for bringing this up!

Cheers,

 -Ben


[1] https://reviews.freebsd.org/D848

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC FreeBSD memory model (was: 8.4.3 release)

Ben Gamari-2
In reply to this post by Viktor Dukhovni
Viktor Dukhovni <[hidden email]> writes:

> On Thu, Jul 05, 2018 at 09:32:31AM -0400, Ben Gamari wrote:
>
>> We use a much different memory allocation strategy on FreeBSD which
>> (AFAIK) does not allow one to reserve address space without also
>> committing.
>
> Here's a demo of mapping in a 1TB heap on FreeBSD 11.1, on a machine
> with "just" 64GB of RAM and 160GB swap.  I would expect anon memory
> mappings to behave similarly on older systems.
>
I have opened #15348 [1] to track the issue.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/ticket/15348

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC FreeBSD memory model (was: 8.4.3 release)

Viktor Dukhovni
In reply to this post by Ben Gamari-3
On Thu, Jul 05, 2018 at 10:20:30PM -0400, Ben Gamari wrote:

> Hmm, it's possible this could be fixed fairly easily in that case. The
> original reason for disabling the two-step allocator is #12695, where
> GHC failed to build due to MAP_NORESERVE being undefined. I had assumed
> that this meant that reservation-only mappings weren't defined however
> now that I look again at the mmap(2) manpage it looks like I
> am probably wrong. MAP_NORESERVE merely flags to the system that swap
> space should not be reserved for the mapping.

Right, absence of MAP_NORESERVE does not mean that all the pages
will be reserved in advance.  However, the VM behaviour may be
configuration-dependent:

    https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING

    The vm.overcommit sysctl defines the overcommit behaviour of
    the vm subsystem. The virtual memory system always does accounting
    of the swap space reservation, both total for system and per-user.
    Corresponding values are available through sysctl vm.swap_total,
    that gives the total bytes available for swapping, and
    vm.swap_reserved, that gives number of bytes that may be needed
    to back all currently allocated anonymous memory. Setting bit
    0 of the vm.overcommit sysctl causes the virtual memory system
    to return failure to the process when allocation of memory
    causes vm.swap_reserved to exceed vm.swap_total. Bit 1 of the
    sysctl enforces RLIMIT_SWAP limit (see getrlimit(2)). Root is
    exempt from this limit. Bit 2 allows to count most of the
    physical memory as allocatable, except wired and free reserved
    pages (accounted by vm.stats.vm.v_free_target and
    vm.stats.vm.v_wire_count sysctls, respectively).

I have the default vm.overcommmit setting:

    $ sysctl vm.overcommit
    vm.overcommit: 0

in which "bit 0" is off, so processes can allocate more anonymous
memory than available swap.  With vm.overcommit=1 the 1TB mmap()
fails (surprisingly EINVAL rather than ENOMEM), while a 1MB mmap()
succeeds.

> My only question is how one performs reservation-and-commit mappings on
> FreeBSD. This is important since without committing any access to the
> mapping may crash the program in the case of OOM. Does FreeBSD simply
> not provide a way to safely map known-good memory?

With vm.overcommit=0, I don't off-hand know of a way to map anonymous
memory that's guaranteed to not later segfault on first access.

One way to avoid issues when vm.overcommit=1 is to use the MAP_GUARD
flag to reserve a mapping without allocating any pages.  And then
(as needed) explicitly map pages within the reserved range.

    $ cat foo.c
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <err.h>
    #include <sys/mman.h>

    int main(int argc, char **argv)
    {
        size_t heapmax = 1ULL << 40; /* 1TB */
        size_t heaplen = 1ULL << 20; /* 1MB */
        unsigned char *heap;
        unsigned char *heap2;

        /* Reserve 1 TB of address-space */
        heap = mmap(NULL, heapmax, PROT_NONE, MAP_GUARD, -1, 0);
        if (heap == MAP_FAILED)
            err(1, "mmap");
        printf ("%p(%zd)\n", heap, heapmax);

        /* Allocate last 1MB of the 1TB address-space */
        heap2 = &heap[heapmax - heaplen];
        heap2 = mmap(heap2, heaplen, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE|MAP_FIXED, -1, 0);
        if (heap2 == MAP_FAILED)
            err(1, "mmap");

        /* Use the allocated space */
        heap2[0] = 'A';
        heap2[heaplen-1] = 'z';
        printf ("%p(%zd) %c %c\n", heap, heaplen, heap2[0], heap2[heaplen-1]);
        sleep(20);
        return 0;
    }

    $ ./foo & sleep 1; pid=$! ; cat /proc/$pid/map; ps -o vsz= -o rss= $pid ; wait
    [1] 84867
    0x800e00000(1099511627776)
    0x800e00000(1048576) A z
    0x400000 0x401000 1 0 0xfffff80f04f75780 r-x 2 0 0x9210 COW NC vnode /tmp/foo NCH -1
    0x600000 0x601000 1 0 0xfffff80b872ed1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800600000 0x800621000 33 0 0xfffff80011df3780 r-x 173 76 0x1000 COW NC vnode /libexec/ld-elf.so.1 NCH -1
    0x800621000 0x800642000 22 0 0xfffff80b872ed690 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800820000 0x800821000 1 0 0xfffff80d348e3c30 rw- 1 0 0x3000 COW NNC vnode /libexec/ld-elf.so.1 CH 1001
    0x800821000 0x800822000 1 0 0xfffff80f432df690 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x800822000 0x8009b4000 402 0 0xfffff8000d720e10 r-x 173 76 0x1000 COW NC vnode /lib/libc.so.7 NCH -1
    0x8009b4000 0x800bb4000 0 0 0xfffff8035779ea50 --- 1 0 0x2000 NCOW NNC default - NCH -1
    0x800bb4000 0x800bc0000 12 0 0xfffff8084feace10 rw- 1 0 0x3000 COW NNC vnode /lib/libc.so.7 CH 1001
    0x800bc0000 0x800bda000 5 0 0xfffff80682dcfc30 rw- 2 0 0x3000 NCOW NNC default - CH 1001
    0x800c00000 0x800e00000 9 0 0xfffff80682dcfc30 rw- 2 0 0x3000 NCOW NNC default - CH 1001
    0x800e00000 0x10800d00000 0 0 0 --- 0 0 0x0 COW NC none - NCH -1
    0x10800d00000 0x10800e00000 2 0 0xfffff8018644c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x10800e00000 0x10801000000 6 0 0xfffff80b76b20d20 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x7fffdffff000 0x7ffffffdf000 0 0 0 --- 0 0 0x0 NCOW NNC none - NCH -1
    0x7ffffffdf000 0x7ffffffff000 3 0 0xfffff80c6b72c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001
    0x7ffffffff000 0x800000000000 0 0 0xfffff800117b6000 r-x 100 0 0x6 NCOW NNC default - NCH -1
    9340 2072
    [1]+  Done                    ./foo

Note the 1TB-1MB hole in the process memory map:

    0x800e00000 0x10800d00000 0 0 0 --- 0 0 0x0 COW NC none - NCH -1

followed by a 1MB mapping:

    0x10800d00000 0x10800e00000 2 0 0xfffff8018644c1e0 rw- 1 0 0x3000 NCOW NNC default - CH 1001

Note also that the "vsz" does not include the hole.  So we are
guaranteed exclusive use of a virtual address range, but it is not
initially allocated, and later allocations can proceed incrementally.
Those later allocation may or may not be subject to overcommit
with OOM segfaults depending on vm.overcommit.

--
        Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.4.3 released

Ben Gamari-2
In reply to this post by Jannis Limperg
Jannis Limperg <[hidden email]> writes:

> Hej Ben,
>
> the release page for GHC 8.4.3 is currently missing a Fedora binary. Is
> this intentional?
>
Fixed. Sorry for the latency. My Fedora build environment died so it
took some time to bring things up again.

Cheers,

- Ben


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment