1. 14 Mar, 2006 1 commit
  2. 21 Oct, 2005 2 commits
    • simonmar's avatar
      [project @ 2005-10-21 14:45:59 by simonmar] · 685095d3
      simonmar authored
      Itimer.h has moved into posix/
      685095d3
    • 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
  3. 12 Sep, 2005 1 commit
  4. 28 Jul, 2005 1 commit
  5. 26 Jul, 2005 1 commit
  6. 25 Jul, 2005 1 commit
  7. 10 May, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-05-10 13:25:41 by simonmar] · bf821981
      simonmar authored
      Two SMP-related changes:
      
        - New storage manager interface:
      
          bdescr *allocateLocal(StgRegTable *reg, nat words)
      
          which allocates from the current thread's nursery (being careful
          not to clash with the heap pointer).  It can do this without
          taking any locks; the lock only has to be taken if a block needs
          to be allocated.  allocateLocal() is now used instead of allocate()
          in a few PrimOps.
      
          This removes locks from most Integer operations, cutting down
          the overhead for SMP a bit more.
      
          To make this work, we have to be able to grab the current thread's
          Capability out of thin air (i.e. when called from GMP), so the
          Capability subsystem needs to keep a hash from thread IDs to
          Capabilities.
      
        - Small MVar optimisation: instead of taking the global
          storage-manager lock, do our own locking of MVars with a bit of
          inline assembly (x86 only for now).
      bf821981
  8. 27 Apr, 2005 1 commit
  9. 22 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-22 12:28:00 by simonmar] · ec0984a9
      simonmar authored
      - Now that labels are always prefixed with '&' in .hc code, we have to
        fix some sloppiness in the RTS .cmm code.  Fortunately it's not too
        painful.
      
      - SMP: acquire/release the storage manager lock around
        atomicModifyMutVar#.  This is a hack: atomicModifyMutVar# isn't
        atomic under SMP otherwise, but the SM lock is a large sledgehammer.
        I think I'll apply the sledgehammer to the MVar primitives too, for
        the time being.
      ec0984a9
  10. 08 Mar, 2005 1 commit
    • wolfgang's avatar
      [project @ 2005-03-08 04:45:29 by wolfgang] · f97dcf9f
      wolfgang authored
      Mac OS X:
      Kill HaskellSupport.framework.
      Instead, look for GMP.framework (a framework-version of libgmp), else look
      for a normal -lgmp as usual.
      The other part of HaskellSupport.framework, dlcompat, is no longer needed
      (as of Mac OS X 10.3, it's included in libSystem).
      It's enough to just use the normal configure tests for -ldl.
      
      MERGE TO STABLE
      f97dcf9f
  11. 28 Feb, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-02-28 17:01:13 by simonmar] · 6d194f48
      simonmar authored
      Optimisation: the update code only needs to check whether the closure
      being updated is a BLACKHOLE_BQ if it has been blackholed; which is
      only the case after lazy blackholing has taken place.
      
      So to avoid this unnecessary cost, we have two kinds of update frame:
      one which checks for BLACKHOLE_BQ and one that doesn't, and the lazy
      blackholing algorithm converts the latter kind into the former as it
      replaces thunks with blackholes.
      6d194f48
  12. 23 Feb, 2005 1 commit
  13. 27 Jan, 2005 1 commit
  14. 20 Jan, 2005 1 commit
  15. 13 Jan, 2005 1 commit
  16. 18 Nov, 2004 1 commit
  17. 12 Oct, 2004 1 commit
  18. 03 Oct, 2004 1 commit
  19. 27 Aug, 2004 1 commit
  20. 19 Aug, 2004 1 commit
  21. 13 Aug, 2004 1 commit
  22. 10 May, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-05-10 10:26:07 by simonmar] · d28ae8e1
      simonmar authored
      Hack to generate correct dependencies for the RTS.  We now #define
      PROFILING, THREADED_RTS and DEBUG when generating dependencies so that
      we get (hopefully) a superset of all the deps.
      d28ae8e1
  23. 25 Feb, 2004 2 commits
  24. 24 Feb, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-02-24 17:33:32 by simonmar] · cd20fd58
      simonmar authored
      Experimental support for RTS-only "ways"
      
      HEADS UP!  This changes the way that the threaded RTS is used, and
      also the use of debugging RTSs:
      
        - We always build threaded and debugging variants of the RTS now.
          The --enable-threaded-rts configure option is ignored (and will
          be removed at some point).
      
        - New option:  -debug     enables the debugging RTS
      
        - New option:  -threaded  enables the threaded RTS.  When the threaded
          RTS is stable enough, we might make it the default.
      
      The new options just cause a different variant of the RTS to be linked
      in, and they cause one or two extra options to be enabled too.  The
      implementation is via the usual ways machinery in the compiler, except
      that these ways are labelled as RTS-only, and so don't require
      rebuilding all the libraries too.
      
      All of this means we can ship threaded and debugging RTSs with GHC, so
      that users don't need to fetch and build a GHC source tree to use
      them.
      
      I'd like to get this functionality into 6.2.1 if possible, so please
      test (I'm willing to stretch the definition of "interface change" to
      accomodate this, since having a threaded RTS available without having
      to build GHC will be a big win for the Visual Studio project).
      cd20fd58
  25. 21 Sep, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-09-21 22:20:51 by wolfgang] · 85aa72b9
      wolfgang authored
      Bound Threads
      =============
      
      Introduce a way to use foreign libraries that rely on thread local state
      from multiple threads (mainly affects the threaded RTS).
      
      See the file threads.tex in CVS at haskell-report/ffi/threads.tex
      (not entirely finished yet) for a definition of this extension. A less formal
      description is also found in the documentation of Control.Concurrent.
      
      The changes mostly affect the THREADED_RTS (./configure --enable-threaded-rts),
      except for saving & restoring errno on a per-TSO basis, which is also necessary
      for the non-threaded RTS (a bugfix).
      
      Detailed list of changes
      ------------------------
      
      - errno is saved in the TSO object and restored when necessary:
      ghc/includes/TSO.h, ghc/rts/Interpreter.c, ghc/rts/Schedule.c
      
      - rts_mainLazyIO is no longer needed, main is no special case anymore
      ghc/includes/RtsAPI.h, ghc/rts/RtsAPI.c, ghc/rts/Main.c, ghc/rts/Weak.c
      
      - passCapability: a new function that releases the capability and "passes"
        it to a specific OS thread:
      ghc/rts/Capability.h ghc/rts/Capability.c
      
      - waitThread(), scheduleWaitThread() and schedule() get an optional
        Capability *initialCapability passed as an argument:
      ghc/includes/SchedAPI.h, ghc/rts/Schedule.c, ghc/rts/RtsAPI.c
      
      - Bound Thread scheduling (that's what this is all about):
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - new Primop isCurrentThreadBound#:
      ghc/compiler/prelude/primops.txt.pp, ghc/includes/PrimOps.h, ghc/rts/PrimOps.hc,
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - a simple function, rtsSupportsBoundThreads, that returns true if THREADED_RTS
        is defined:
      ghc/rts/Schedule.h, ghc/rts/Schedule.c
      
      - a new implementation of forkProcess (the old implementation stays in place
        for the non-threaded case). Partially broken; works for the standard
        fork-and-exec case, but not for much else. A proper forkProcess is
        really next to impossible to implement:
      ghc/rts/Schedule.c
      
      - Library support for bound threads:
          Control.Concurrent.
            rtsSupportsBoundThreads, isCurrentThreadBound, forkOS,
            runInBoundThread, runInUnboundThread
      libraries/base/Control/Concurrent.hs, libraries/base/Makefile,
      libraries/base/include/HsBase.h, libraries/base/cbits/forkOS.c (new file)
      85aa72b9
  26. 05 Aug, 2003 1 commit
  27. 24 Jul, 2003 1 commit
  28. 23 Jul, 2003 1 commit
  29. 24 Jun, 2003 1 commit
  30. 29 May, 2003 2 commits
    • sof's avatar
      [project @ 2003-05-29 14:39:26 by sof] · a7d8f437
      sof authored
      Support for interop'ing with .NET via FFI declarations along the
      lines of what Hugs98.NET offers, see
      
       http://haskell.org/pipermail/cvs-hugs/2003-March/001723.html
      
      for FFI decl details.
      
      To enable, configure with --enable-dotnet + have a look
      in ghc/rts/dotnet/Makefile for details of what tools are needed to
      build the .NET interop layer (tools from VS.NET / Framework SDK.)
      
      The commit doesn't include some library additions + wider-scale
      testing is required before this extension can be regarded as available
      for general use. 'foreign import dotnet' is currently only supported
      by the C backend.
      a7d8f437
    • simonmar's avatar
      [project @ 2003-05-29 12:59:55 by simonmar] · 2841c2c3
      simonmar authored
      Clean AutoApply.hc too.
      2841c2c3
  31. 29 Mar, 2003 1 commit
  32. 21 Feb, 2003 1 commit
    • sof's avatar
      [project @ 2003-02-21 05:34:12 by sof] · 5b4f5a6a
      sof authored
      Asynchronous / non-blocking I/O for Win32 platforms.
      
      This commit introduces a Concurrent Haskell friendly view of I/O on
      Win32 platforms. Through the use of a pool of worker Win32 threads, CH
      threads may issue asynchronous I/O requests without blocking the
      progress of other CH threads. The issuing CH thread is blocked until
      the request has been serviced though.
      
      GHC.Conc exports the primops that take care of issuing the
      asynchronous I/O requests, which the IO implementation now takes
      advantage of. By default, all Handles are non-blocking/asynchronous,
      but should performance become an issue, having a per-Handle flag for
      turning off non-blocking could easily be imagined&introduced.
      
      [Incidentally, this thread pool-based implementation could easily be
      extended to also allow Haskell code to delegate the execution of
      arbitrary pieces of (potentially blocking) external code to another OS
      thread. Given how relatively gnarly the locking story has turned out
      to be with the 'threaded' RTS, that may not be such a bad idea.]
      5b4f5a6a
  33. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  34. 12 Oct, 2002 1 commit
    • wolfgang's avatar
      [project @ 2002-10-12 23:12:08 by wolfgang] · 31442604
      wolfgang authored
      Make the Mac OS X build use the HaskellSupport.framework (a MacOS-style "framework" that includes the required libraries libgmp and dlcompat) if it is present. The HaskellSupport.framework is not yet in CVS, but is available from me.
      31442604
  35. 09 Aug, 2002 3 commits