1. 27 Jul, 2015 2 commits
  2. 24 Jul, 2015 1 commit
  3. 23 Jul, 2015 1 commit
  4. 22 Jul, 2015 2 commits
    • gcampax's avatar
      Two step allocator for 64-bit systems · 0d1a8d09
      gcampax authored
      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
    • Simon Marlow's avatar
      Eliminate zero_static_objects_list() · b949c96b
      Simon Marlow authored
      In a workload with a large amount of code, zero_static_objects_list()
      takes a significant amount of time, and furthermore it is in the
      single-threaded part of the GC.
      This patch uses a slightly fiddly scheme for marking objects on the
      static object lists, using a flag in the low 2 bits that flips between
      two states to indicate whether an object has been visited during this
      GC or not.  We also have to take into account objects that have not
      been visited yet, which might appear at any time due to runtime linking.
      Test Plan: validate
      Reviewers: austin, bgamari, ezyang, rwbarton
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1076
  5. 15 Jul, 2015 2 commits
  6. 10 Jul, 2015 1 commit
  7. 07 Jul, 2015 2 commits
    • Sergei Trofimovich's avatar
      fix EBADF unqueueing in select backend (Trac #10590) · 5857e0af
      Sergei Trofimovich authored
      Alexander found a interesting case:
      1. We have a queue of two waiters in a blocked_queue
      2. first file descriptor changes state to RUNNABLE,
         second changes to INVALID
      3. awaitEvent function dequeued RUNNABLE thread to a
         run queue and attempted to dequeue INVALID descriptor
         to a run queue.
      Unqueueing INVALID fails thusly:
              #3  0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found")
                                     at rts/RtsMessages.c:42
              #4  0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249
              #5  0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719
              #6  0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67
              #7  0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75
              #8  0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415
      The problem here is a throwToSingleThreaded function that tries
      to unqueue a TSO from blocked_queue, but awaitEvent function
      leaves blocked_queue in a inconsistent state while traverses
      over blocked_queue:
            case RTS_FD_IS_READY:
                    debugBelch("Waking up blocked thread %lu\n",
                               (unsigned long)tso->id));
                tso->why_blocked = NotBlocked;
                tso->_link = END_TSO_QUEUE;              // Here we break the queue head
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      Test Plan: tested on a sample from T10590
      Reviewers: austin, bgamari, simonmar
      Reviewed By: bgamari, simonmar
      Subscribers: qnikst, thomie, bgamari
      Differential Revision: https://phabricator.haskell.org/D1024
      GHC Trac Issues: #10590, #4934
    • Simon Marlow's avatar
      Update comments around blackholes · ebfc2fb8
      Simon Marlow authored
      Test Plan: validate
      Reviewers: austin, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1047
  8. 06 Jul, 2015 1 commit
  9. 05 Jul, 2015 1 commit
  10. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      rts/stg/SMP.h support is implemented.
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      Fixes #9863
      Test Plan: validate (on powerpc, too)
      Reviewers: simonmar, trofi, erikd, austin
      Reviewed By: trofi
      Subscribers: bgamari, arnons1, kgardas, thomie
      Differential Revision: https://phabricator.haskell.org/D629
      GHC Trac Issues: #9863
  11. 30 Jun, 2015 1 commit
  12. 26 Jun, 2015 2 commits
    • Simon Marlow's avatar
      Fix deadlock (#10545) · 111ba4be
      Simon Marlow authored
      yieldCapability() was not prepared to be called by a Task that is not
      either a worker or a bound Task.  This could happen if we ended up in
      yieldCapability via this call stack:
      and there were a few other ways this could happen via requestSync.
      The fix is to handle this case in yieldCapability(): when the Task is
      not a worker or a bound Task, we put it on the returning_workers
      queue, where it will be woken up again.
      Summary of changes:
      * `yieldCapability`: factored out subroutine waitForWorkerCapability`
      * `waitForReturnCapability` renamed to `waitForCapability`, and
        factored out subroutine `waitForReturnCapability`
      * `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does
        not take a lock and no longer tests if `!isBoundTask()`
      * `yieldCapability` adjusted for refactorings, only change in behavior
        is when it is not a worker or bound task.
      Test Plan:
      * new test concurrent/should_run/performGC
      * validate
      Reviewers: niteria, austin, ezyang, bgamari
      Subscribers: thomie, bgamari
      Differential Revision: https://phabricator.haskell.org/D997
      GHC Trac Issues: #10545
    • Simon Marlow's avatar
      Fix for crash in setnumcapabilities001 · be0ce871
      Simon Marlow authored
      getNewNursery() was unconditionally incrementing next_nursery, which
      is normally fine but it broke an assumption in
      storageAddCapabilities().  This manifested as an occasional crash in
      the setnumcapabilities001 test.
  13. 23 Jun, 2015 1 commit
    • Sergei Trofimovich's avatar
      powerpc: add basic support for PLT relocations (#10402) · c0847967
      Sergei Trofimovich authored
      Commit a93ab43a
      enabled support for proper PIC relocations from
      Commit adds support for relocations of type:
      They are used only when GHC is built in
      Verified by running the following test:
          // cat a.c
          #include <stdio.h>
          void ffi_a_hello (int i) {
              fprintf (stderr, "WEEEEEEEE: i=%d\n", i);
          -- cat A.hs
          {-# LANGUAGE ForeignFunctionInterface #-}
          module A where
          import Foreign.C
          foreign import ccall "ffi_a_hello" a :: CInt -> IO ()
          # ghc -fPIC -c a.c -fforce-recomp
          # ghc -fPIC -c A.hs -fforce-recomp
          # ghc --interactive ./a.o A
          *A> a 42
          WEEEEEEEE: i=42
      See gory details in Trac #10402.
      Signed-off-by: default avatarColin Watson <cjwatson@debian.org>
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      Reviewed By: bgamari, austin
      Differential Revision: https://phabricator.haskell.org/D996
      GHC Trac Issues: #10402
  14. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      When we introduced user-friendly library names
      (e.g. unix- instead of
      unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
      be written out by ghc-cabal, $1_$2_LIB_NAME.
      What I didn't realize at the time was that this conflicts
      with an existing variable in the build system, $1_$2_$3_LIB_NAME,
      which (confusingly) refers to something like
      'libHSunix-'.  This is pretty
      confusing (despite never conflicting), so I renamed this variable
      to LIB_FILE for enhanced greppability.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: austin
      Subscribers: thomie, bgamari
      Differential Revision: https://phabricator.haskell.org/D1002
  15. 16 Jun, 2015 1 commit
  16. 12 Jun, 2015 2 commits
  17. 08 Jun, 2015 1 commit
    • Simon Marlow's avatar
      Fix for CAF retention when dynamically loading & unloading code · 19ec6a84
      Simon Marlow authored
      In a situaion where we have some statically-linked code and we want to
      load and unload a series of objects, we need the CAFs in the
      statically-linked code to be retained indefinitely, while the CAFs in
      the dynamically-linked code should be GC'd as normal, so that we can
      detect when the code is unloadable.  This was wrong before - we GC'd
      CAFs in the static code, leading to a crash in the rare case where we
      use a CAF, GC it, and then load a new object that uses it again.
      I also did some tidy up: RtsConfig now has a field keep_cafs to
      indicate whether we want CAFs to be retained in static code.
  18. 01 Jun, 2015 2 commits
    • Simon Marlow's avatar
      Don't call DEAD_WEAK finalizer again on shutdown (#7170) · dfdc50d6
      Simon Marlow authored
      There's a race condition like this:
        # A foreign pointer gets promoted to the last generation
        # It has its finalizer called manually
        # We start shutting down the runtime in `hs_exit_` from the main
        # A minor GC starts running (`scheduleDoGC`) on one of the threads
        # The minor GC notices that we're in `SCHED_INTERRUPTING` state and
          advances to `SCHED_SHUTTING_DOWN`
        # The main thread tries to do major GC (with `scheduleDoGC`), but it
          exits early because we're in `SCHED_SHUTTING_DOWN` state
        # We end up with a `DEAD_WEAK` left on the list of weak pointers of
          the last generation, because it relied on major GC removing it from
          that list
      This change:
        * Ignores DEAD_WEAK finalizers when shutting down
        * Makes the major GC on shutdown more likely
        * Fixes a bogus assert
      Test Plan:
      before this diff https://ghc.haskell.org/trac/ghc/ticket/7170#comment:5
      reproduced and after it doesn't
      Reviewers: ezyang, austin, simonmar
      Reviewed By: simonmar
      Subscribers: bgamari, thomie
      Differential Revision: https://phabricator.haskell.org/D921
      GHC Trac Issues: #7170
    • Edward Z. Yang's avatar
      Newline after type of allocate(). · f82e8665
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
  19. 23 May, 2015 1 commit
  20. 06 May, 2015 1 commit
    • Javran Cheng's avatar
      rts: add "-no-rtsopts-suggestions" option · 477f514f
      Javran Cheng authored
      Depends on D767
      Setting this flag prevents RTS from giving RTS suggestions like "Use
      `+RTS -Ksize -RTS' to increase it."
      According to the comment @rwbarton made in #9579, sometimes "+RTS"
      suggestions don't make sense (e.g. when the program is precompiled and
      installed through package managers), we can encourage people to
      distribute binaries with either "-no-rtsopts-suggestions" or "-rtsopts".
      Reviewed By: erikd, austin
      Differential Revision: https://phabricator.haskell.org/D809
      GHC Trac Issues: #9579
  21. 17 Apr, 2015 1 commit
    • Javran Cheng's avatar
      Better hints when RTS options not available (Trac #9579) · 51af102e
      Javran Cheng authored
      This patch provides user with a better hint when most RTS options
      are not available (not compiled with `-rtsopts`).
      A new field "rtsOptsEnabled" is added into RtsFlags.MiscFlags to
      tell the availablity of RTS options.
      Some concerns:
      * Unlike other flag fields in "libraries/base/GHC/RTS/Flags.hsc",
        "RtsOptsEnabled" is defined in "includes/RtsAPI.h" and lacks
        constant macros. Therefore In "GHC.RTS", "RtsOptsEnabled" simply
        derives Enum instance and reads as of type "CInt".
      * There are other ways to change RTS options (e.g. `-with-rtsopts`),
        but it might be too verbose to mention.
      Test Plan: validate
      Reviewers: austin, hvr, thomie, simonmar
      Reviewed By: thomie
      Subscribers: thomie, rwbarton
      Differential Revision: https://phabricator.haskell.org/D767
      GHC Trac Issues: #9579
  22. 10 Apr, 2015 1 commit
  23. 07 Apr, 2015 4 commits
  24. 06 Apr, 2015 1 commit
  25. 03 Apr, 2015 1 commit
  26. 22 Mar, 2015 3 commits
  27. 19 Mar, 2015 1 commit
  28. 09 Mar, 2015 1 commit
    • AndreasVoellmy's avatar
      RTS/IOManager: fix trac issue #9722. · 74625d68
      AndreasVoellmy authored
      Whenever the RTS has been inactive for idleGCDelayTime, the idle timer
      fires and calls wakeUpRts(), which in turn calls ioManagerWakeup(),
      which in turn writes a byte (or a few) to a file descriptor (stored in
      the io_manager_wakeup_fd variable) registered by the TimerManager and
      on which the TimerManager will wait. (Note that the write will only
      occur if the file descriptor is non-negative.) When the RTS shuts
      down, it shuts down the TimerManager, and in this process the file
      descriptor stored in io_manager_wakeup_fd is closed. In the error
      case, the idle timer fires after the close of the file occurs, and
      then the write() call in ioManagerWakeup() fails and the
      aforementioned error message gets printed.
      This patch solves the problem by (1) having the TimerManager (via
      Control) write -1 to io_manager_wakeup_fd just before closing the file
      descriptor written in io_manager_wakeup_fd, and (2) having
      ioManagerWakeup() ignore an error returned by write() in the case that
      the write returned -1 and the io_manager_wakeup_fd is -1.
      Reviewers: austin, simonmar, hvr, thomie
      Reviewed By: thomie
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D722
      GHC Trac Issues: #9722