This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 05 Aug, 2009 1 commit
  2. 27 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Basic heap profile support without -prof · cbeb99ef
      Simon Marlow authored
      Now that constructor info tables contain the name of the constructor,
      we can generate useful heap profiles without requiring the whole
      program and libraries to be compiled with -prof.  So now, "+RTS -hT"
      generates a heap profile for any program, dividing the profile by
      constructor.  It wouldn't be hard to add support for grouping
      constructors by module, or to restrict the profile to certain
      constructors/modules/packages.
      
      This means that for the first time we can get heap profiles for GHCi,
      which was previously impossible because the byte-code
      interpreter and linker don't work with -prof.
      cbeb99ef
  3. 15 Dec, 2006 1 commit
  4. 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
  5. 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
  6. 13 May, 2005 1 commit
  7. 27 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-27 09:48:34 by simonmar] · 03d63424
      simonmar authored
      Remove uses of stderr from .cmm code.
      
      We can't reliably refer to stdin/stdout/stderr from .cmm, because the
      C standard doesn't specify whether stderr is a variable or a macro.
      03d63424
  8. 03 Sep, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-09-03 15:28:18 by simonmar] · 95ca6bff
      simonmar authored
      Cleanup: all (well, most) messages from the RTS now go through the
      functions in RtsUtils: barf(), debugBelch() and errorBelch().  The
      latter two were previously called belch() and prog_belch()
      respectively.  See the comments for the right usage of these message
      functions.
      
      One reason for doing this is so that we can avoid spurious uses of
      stdout/stderr by Haskell apps on platforms where we shouldn't be using
      them (eg. non-console apps on Windows).
      95ca6bff
  9. 13 Aug, 2004 2 commits
  10. 18 Jul, 2002 1 commit
  11. 12 Dec, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-12-12 14:31:42 by simonmar] · 55c8be52
      simonmar authored
      - Add a new type of restriction: -hC, which restricts to closures
        whose CCS contains the specified CCs *anywhere* (not just at the
        top).
      
      - Complain if the user tries to request both retainer and biographical
        profiling.  We don't support both simultaneously, because they use
        the same header word in the closure.
      
      - Allow for the fact that the heap might contain some closures which
        don't have a valid retainer set during the heap census.  The only
        known closures of this kind so far are DEAD_WEAK closures.
      
      - Some cruft-removal and renaming of functions to follow conventions.
      55c8be52
  12. 22 Nov, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-11-22 14:25:11 by simonmar] · db61851c
      simonmar authored
      Retainer Profiling / Lag-drag-void profiling.
      
      This is mostly work by Sungwoo Park, who spent a summer internship at
      MSR Cambridge this year implementing these two types of heap profiling
      in GHC.
      
      Relative to Sungwoo's original work, I've made some improvements to
      the code:
      
         - it's now possible to apply constraints to retainer and LDV profiles
           in the same way as we do for other types of heap profile (eg.
           +RTS -hc{foo,bar} -hR -RTS gives you a retainer profiling considering
           only closures with cost centres 'foo' and 'bar').
      
         - the heap-profile timer implementation is cleaned up.
      
         - heap profiling no longer has to be run in a two-space heap.
      
         - general cleanup of the code and application of the SDM C coding
           style guidelines.
      
      Profiling will be a little slower and require more space than before,
      mainly because closures have an extra header word to support either
      retainer profiling or LDV profiling (you can't do both at the same
      time).
      
      We've used the new profiling tools on GHC itself, with moderate
      success.  Fixes for some space leaks in GHC to follow...
      db61851c
  13. 19 Apr, 2000 1 commit
  14. 03 Apr, 2000 1 commit
  15. 08 Mar, 2000 1 commit
    • simonmar's avatar
      [project @ 2000-03-08 17:48:24 by simonmar] · de896403
      simonmar authored
      - generalise the per-module initialisation stubs so that we use it
        in normal (non-profiled) code too.  The initialisation stubs are
        now called '__init_<module>' rather than '_reg<module>'.
      
      - Register foreign exported functions as stable pointers in the
        initialisation code for the module.  This fixes the foreign export
        problems reported by several people.
      
      - remove the concept of "module groups" from the profiling subsystem.
      
      - change the profiling semantics slightly; it should be unnecessary
        to use '-caf-all' to get reasonable profiles now.
      de896403
  16. 07 Mar, 2000 1 commit
  17. 17 Feb, 2000 1 commit
  18. 03 Dec, 1999 1 commit
  19. 16 Sep, 1999 1 commit
  20. 15 Sep, 1999 1 commit
    • simonmar's avatar
      [project @ 1999-09-15 13:45:14 by simonmar] · 17315bf6
      simonmar authored
      Heap Profiling
      --------------
      
      This commit adds simple hp2ps-style heap profiling.  Just the '-h'
      option is supported so far.
      
      Heap profiles will show the top two cost centres on each cost centre
      stack.
      
      Time/Alloc profiles have been extended to aggregate the costs on a
      per-cost-centre basis and show the table of highest consuming cost
      centres before the full table of cost centre stacks.
      
      Profiles work best if '-caf-all' is used, especially when using
      one of the '-auto' flags.
      17315bf6
  21. 25 Aug, 1999 1 commit
    • simonmar's avatar
      [project @ 1999-08-25 16:11:43 by simonmar] · c6ab4bfa
      simonmar authored
      Support for thread{WaitRead,WaitWrite,Delay}.  These should behave
      identically to the 3.02 implementations.
      
      We now have the virtual timer on during all program runs, which ticks
      at 50Hz by default.  This is used to implement threadDelay, so you
      won't get any better granularity than the tick frequency
      unfortunately.  It remains to be seen whether using the virtual timer
      will have a measurable impact on performance for non-threadDelaying
      programs.
      
      All operations in the I/O subsystem should now be non-blocking with
      respect to other running Haskell threads.  It remains to be seen
      whether this will have a measurable performance impact on
      non-concurrent programs (probably not).
      c6ab4bfa
  22. 05 Feb, 1999 1 commit
  23. 02 Dec, 1998 1 commit