1. 05 Nov, 2019 1 commit
  2. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  3. 13 Jun, 2017 1 commit
  4. 11 May, 2017 1 commit
  5. 29 Apr, 2017 1 commit
  6. 23 Apr, 2017 1 commit
  7. 12 May, 2016 1 commit
  8. 04 May, 2016 1 commit
  9. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      rts: Make MBLOCK_SPACE_SIZE dynamic · f5974c88
      Ben Gamari authored
      Previously this was introduced in D524 as a compile-time constant.
      Sadly, this isn't flexible enough to allow for environments where
      ulimits restrict the maximum address space size (see, for instance,
      
      Consequently, we are forced to make this dynamic. In principle this
      shouldn't be so terrible as we can place both the beginning and end
      addresses within the same cache line, likely incurring only one or so
      additional instruction in HEAP_ALLOCED.
      
      Test Plan: validate
      
      Reviewers: austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1353
      
      GHC Trac Issues: #10877
      f5974c88
  10. 28 Aug, 2015 1 commit
    • Erik de Castro Lopo's avatar
      RTS: Reduce MBLOCK_SPACE_SIZE on AArch64 · 38c98e4f
      Erik de Castro Lopo authored
      Commit 0d1a8d09 added a two step allocator for 64 bit systems. This
      allocator mmaps a huge (1 TB) chunk of memory out of which it does
      smaller allocations. On AArch64/Arm64 linux, this mmap was failing
      due to the Arm64 Linux kernel parameter CONFIG_ARM64_VA_BITS
      defaulting to 39 bits.
      
      Therefore reducing the AArch64 value for MBLOCK_SPACE_SIZE to make
      this allocation 1/4 TB while remaining 1 TB for other archs.
      
      Reviewers: ezyang, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1171
      
      GHC Trac Issues: #10682
      38c98e4f
  11. 22 Jul, 2015 1 commit
    • gcampax's avatar
      Two step allocator for 64-bit systems · 0d1a8d09
      gcampax authored
      Summary:
      The current OS memory allocator conflates the concepts of allocating
      address space and allocating memory, which makes the HEAP_ALLOCED()
      implementation excessively complicated (as the only thing it cares
      about is address space layout) and slow. Instead, what we want
      is to allocate a single insanely large contiguous block of address
      space (to make HEAP_ALLOCED() checks fast), and then commit subportions
      of that in 1MB blocks as we did before.
      This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for
      certain OSes.
      
      Test Plan: validate
      
      Reviewers: simonmar, ezyang, austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D524
      
      GHC Trac Issues: #9706
      0d1a8d09
  12. 20 Aug, 2014 1 commit
  13. 01 Oct, 2013 1 commit
  14. 07 Sep, 2012 1 commit
    • Simon Marlow's avatar
      Deprecate lnat, and use StgWord instead · 41737f12
      Simon Marlow authored
      lnat was originally "long unsigned int" but we were using it when we
      wanted a 64-bit type on a 64-bit machine.  This broke on Windows x64,
      where long == int == 32 bits.  Using types of unspecified size is bad,
      but what we really wanted was a type with N bits on an N-bit machine.
      StgWord is exactly that.
      
      lnat was mentioned in some APIs that clients might be using
      (e.g. StackOverflowHook()), so we leave it defined but with a comment
      to say that it's deprecated.
      41737f12
  15. 13 Aug, 2010 1 commit
  16. 09 Jul, 2010 1 commit
    • Sergei Trofimovich's avatar
      * storage manager: preserve upper address bits on 64bit machines (thanks to zygoloid) · d12690d5
      Sergei Trofimovich authored
      Patch does not touch amd64 as it's address lengts is 48 bits at most, so amd64 is unaffected.
      
      the issue: during ia64 ghc bootstrap (both 6.10.4 and 6.12.3) I
      got the failure on stage2 phase:
          "inplace/bin/ghc-stage2"   -H32m -O -H64m -O0 -w ...
          ghc-stage2: internal error: evacuate: strange closure type 15
              (GHC version 6.12.3 for ia64_unknown_linux)
              Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
          make[1]: *** [libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o] Aborted
      
      gdb backtrace (break on 'barf'):
      Breakpoint 1 at 0x400000000469ec31: file rts/RtsMessages.c, line 39.
      (gdb) run -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
      Starting program: /var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/lib/ghc-stage2 -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
      [Thread debugging using libthread_db enabled]
      
      Breakpoint 1, barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
      39        va_start(ap,s);
      (gdb) bt
      #0  barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
      #1  0x400000000474a1e0 in evacuate (p=0x6000000000147958) at rts/sm/Evac.c:756
      #2  0x40000000046d68c0 in scavenge_srt (srt=0x6000000000147958, srt_bitmap=7) at rts/sm/Scav.c:348
      ...
      
      > 16:52:53 < zygoloid> slyfox: i'm no ghc expert but it looks like HEAP_ALLOCED_GC(q)
      >                      is returning true for a FUN_STATIC closure
      > 17:18:43 < zygoloid> try: p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
      > 17:19:12 < slyfox> (gdb) p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
      > 17:19:12 < slyfox> $1 = 0
      > 17:19:40 < zygoloid> i /think/ that means the mblock_cache is broken
      > 17:22:45 < zygoloid> i can't help further. however i am suspicious that you seem to have pointers with similar-looking low 33
      >                      bits and different high 4 bits, and it looks like such pointers get put into the same bucket in
      >                      mblock_cache.
      ...
      > 17:36:16 < zygoloid> slyfox: try changing the definition of MbcCacheLine to StgWord64, see if that helps
      > 17:36:31 < zygoloid> that's in includes/rts/storage/MBlock.h
      And it helped!
      d12690d5
  17. 03 Aug, 2009 2 commits
  18. 02 Aug, 2009 1 commit
    • Simon Marlow's avatar
      RTS tidyup sweep, first phase · a2a67cd5
      Simon Marlow authored
      The first phase of this tidyup is focussed on the header files, and in
      particular making sure we are exposinng publicly exactly what we need
      to, and no more.
      
       - Rts.h now includes everything that the RTS exposes publicly,
         rather than a random subset of it.
      
       - Most of the public header files have moved into subdirectories, and
         many of them have been renamed.  But clients should not need to
         include any of the other headers directly, just #include the main
         public headers: Rts.h, HsFFI.h, RtsAPI.h.
      
       - All the headers needed for via-C compilation have moved into the
         stg subdirectory, which is self-contained.  Most of the headers for
         the rest of the RTS APIs have moved into the rts subdirectory.
      
       - I left MachDeps.h where it is, because it is so widely used in
         Haskell code.
       
       - I left a deprecated stub for RtsFlags.h in place.  The flag
         structures are now exposed by Rts.h.
      
       - Various internal APIs are no longer exposed by public header files.
      
       - Various bits of dead code and declarations have been removed
      
       - More gcc warnings are turned on, and the RTS code is more
         warning-clean.
      
       - More source files #include "PosixSource.h", and hence only use
         standard POSIX (1003.1c-1995) interfaces.
      
      There is a lot more tidying up still to do, this is just the first
      pass.  I also intend to standardise the names for external RTS APIs
      (e.g use the rts_ prefix consistently), and declare the internal APIs
      as hidden for shared libraries.
      a2a67cd5
  19. 09 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Redesign 64-bit HEAP_ALLOCED (FIX #2934 at the same time) · 9fe7b8ea
      Simon Marlow authored
      After much experimentation, I've found a formulation for HEAP_ALLOCED
      that (a) improves performance, and (b) doesn't have any race
      conditions when used concurrently.  GC performance on x86_64 should be
      improved slightly.  See extensive comments in MBlock.h for the
      details.
      9fe7b8ea
  20. 30 Jan, 2009 1 commit
  21. 09 Sep, 2008 1 commit
  22. 16 Apr, 2008 1 commit
  23. 27 Jun, 2007 1 commit
    • Simon Marlow's avatar
      +RTS -xbXXXXX sets the "heap base" to 0xXXXXXX · 73637ad6
      Simon Marlow authored
      When debugging the GC and storage manager we often want repeated runs
      of the program to allocate memory at the same addresses, so that we
      can set watch points.  Unfortunately the OS doesn't always give us
      memory at predictable addresses.  This flag gives the OS a hint as to
      where we would like our memory allocated.  Previously I did this by
      changing the HEAP_BASE setting in MBlock.h and recompiling, this patch
      just adds a flag so I don't have to recompile.
      73637ad6
  24. 24 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Split GC.c, and move storage manager into sm/ directory · ab0e778c
      Simon Marlow authored
      In preparation for parallel GC, split up the monolithic GC.c file into
      smaller parts.  Also in this patch (and difficult to separate,
      unfortunatley):
        
        - Don't include Stable.h in Rts.h, instead just include it where
          necessary.
        
        - consistently use STATIC_INLINE in source files, and INLINE_HEADER
          in header files.  STATIC_INLINE is now turned off when DEBUG is on,
          to make debugging easier.
        
        - The GC no longer takes the get_roots function as an argument.
          We weren't making use of this generalisation.
      ab0e778c
  25. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  26. 02 Mar, 2006 1 commit
  27. 21 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-21 14:02:17 by simonmar] · 03a9ff01
      simonmar authored
      Big re-hash of the threaded/SMP runtime
      
      This is a significant reworking of the threaded and SMP parts of
      the runtime.  There are two overall goals here:
      
        - To push down the scheduler lock, reducing contention and allowing
          more parts of the system to run without locks.  In particular,
          the scheduler does not require a lock any more in the common case.
      
        - To improve affinity, so that running Haskell threads stick to the
          same OS threads as much as possible.
      
      At this point we have the basic structure working, but there are some
      pieces missing.  I believe it's reasonably stable - the important
      parts of the testsuite pass in all the (normal,threaded,SMP) ways.
      
      In more detail:
      
        - Each capability now has a run queue, instead of one global run
          queue.  The Capability and Task APIs have been completely
          rewritten; see Capability.h and Task.h for the details.
      
        - Each capability has its own pool of worker Tasks.  Hence, Haskell
          threads on a Capability's run queue will run on the same worker
          Task(s).  As long as the OS is doing something reasonable, this
          should mean they usually stick to the same CPU.  Another way to
          look at this is that we're assuming each Capability is associated
          with a fixed CPU.
      
        - What used to be StgMainThread is now part of the Task structure.
          Every OS thread in the runtime has an associated Task, and it
          can ask for its current Task at any time with myTask().
      
        - removed RTS_SUPPORTS_THREADS symbol, use THREADED_RTS instead
          (it is now defined for SMP too).
      
        - The RtsAPI has had to change; we must explicitly pass a Capability
          around now.  The previous interface assumed some global state.
          SchedAPI has also changed a lot.
      
        - The OSThreads API now supports thread-local storage, used to
          implement myTask(), although it could be done more efficiently
          using gcc's __thread extension when available.
      
        - I've moved some POSIX-specific stuff into the posix subdirectory,
          moving in the direction of separating out platform-specific
          implementations.
      
        - lots of lock-debugging and assertions in the runtime.  In particular,
          when DEBUG is on, we catch multiple ACQUIRE_LOCK()s, and there is
          also an ASSERT_LOCK_HELD() call.
      
      What's missing so far:
      
        - I have almost certainly broken the Win32 build, will fix soon.
      
        - any kind of thread migration or load balancing.  This is high up
          the agenda, though.
      
        - various performance tweaks to do
      
        - throwTo and forkProcess still do not work in SMP mode
      03a9ff01
  28. 27 Mar, 2005 1 commit
    • panne's avatar
      [project @ 2005-03-27 13:41:13 by panne] · 03dc2dd3
      panne authored
      * Some preprocessors don't like the C99/C++ '//' comments after a
        directive, so use '/* */' instead. For consistency, a lot of '//' in
        the include files were converted, too.
      
      * UnDOSified libraries/base/cbits/runProcess.c.
      
      * My favourite sport: Killed $Id$s.
      03dc2dd3
  29. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9
  30. 10 Nov, 2004 1 commit
    • wolfgang's avatar
      [project @ 2004-11-10 03:20:31 by wolfgang] · 61ccfec1
      wolfgang authored
      Implement the mblock map for 64-bit architectures.
      Fairly primitive data structure, but one 4GB-block, described by a
      12-bit block map, is cached for speed.
      
      Note that I've nuked the ia64-specific version (I think ia64 wants to
      use the general 64-bit solution, too).
      61ccfec1
  31. 12 Sep, 2004 1 commit
  32. 13 Aug, 2004 1 commit
  33. 21 Sep, 2003 1 commit
  34. 29 Aug, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-08-29 16:00:25 by simonmar] · 7dc97354
      simonmar authored
      Initial x86-64 (aka amd64) support.
      
      Unregisterised it works perfectly.  Registerised, I think it's almost
      there, except that I seem to be running into the known codegen bug in
      GCC with register variables (bug #7871 in the gcc bugzilla), which
      means registerised support is basically hosed until the GCC folks
      can get their act together.
      
      We get 8 more registers on amd64, but only 2 more callee-saves
      registers.  The calling convention seems to pass args in registers by
      default, using the previously-callee-saves %rsi and %rdi as two of the
      new arg registers.
      
      I think GHCi should work, since we already have 64-bit ELF support
      thanks to Mat Chapman's work on the IA64 port.  I haven't tried GHCi,
      though.
      
      The native code generator should be a breeze, because it's so similar
      to plain x86.
      7dc97354
  35. 30 Jul, 2003 1 commit
  36. 22 Nov, 2002 1 commit
  37. 21 Oct, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-10-21 11:38:53 by simonmar] · 2be44cb2
      simonmar authored
      Bite the bullet and generalise the central memory allocation scheme.
      Previously we tried to allocate memory starting from a fixed address,
      which was set for each architecture (0x5000000 was a common one), and
      to decide whether a particular address was in the heap or not we would
      do a simple comparison against this address.
      
      This doesn't work too well, because:
      
       - if we dynamically-load some objects above the boundary, the
         heap-allocated test becomes invalid
      
       - on windows we have less control, and the heap might be
         split into multiple sections
      
       - it turns out that on some Linux kernels we don't get memory where
         we asked for it.  This might be a bug in those kernels, but it
         exposes the fragility of our allocation scheme.
      
      The solution is to bite the bullet and maintain a table mapping
      addresses to a value indicating whether that address is in the heap or
      not.  Since we normally allocate heap in chunks of 1Mb, the table is
      quite small: 4k on a 32-bit machine, using one byte for each 1Mb
      block.  Testing an address for heap residency now involves a memory
      access, but the table is normally cache-resident.  I didn't manage to
      measure any slowdown after making the change.
      
      On a 64-bit machine, we'll need to use a 2-level table; I haven't
      implemented that yet.
      
      Now we can generalise the procedure used to grab memory from the OS.
      In the general case, we allocate one megablock more than we need to,
      and trim off the slop around the allocation to leave an aligned chunk.
      The next time around, however, we try to allocate memory right after
      the last chunk allocated, on the grounds that it is aligned and
      probably free: if this doesn't work, we have to back off to the
      general mechanism (it seems to work most of the time).
      
      This cleans up the Windows story too: is_heap_alloced() has gone, and
      we should be able to handle more than 256M of memory (or whatever the
      arbitrary limit was before).
      
      MERGE TO STABLE (after lots of testing)
      2be44cb2
  38. 14 May, 2002 1 commit
  39. 14 Feb, 2002 1 commit