1. 05 Sep, 2006 1 commit
    • Ian Lynagh's avatar
      new RTS flag: -V to modify the resolution of the RTS timer · 93db1991
      Ian Lynagh authored
      Fixed version of an old patch by Simon Marlow. His description read:
       Also, now an arbitrarily short context switch interval may now be
       specified, as we increase the RTS ticker's resolution to match the
       requested context switch interval.  This also applies to +RTS -i (heap
       profiling) and +RTS -I (the idle GC timer).  +RTS -V is actually only
       required for increasing the resolution of the profile timer.
      93db1991
  2. 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
  3. 12 Sep, 2004 1 commit
  4. 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
  5. 22 Feb, 2003 1 commit
    • sof's avatar
      [project @ 2003-02-22 04:51:50 by sof] · 557947d3
      sof authored
      Clean up code&interfaces that deals with timers and asynchrony:
      
      - Timer.{c,h} now defines the platform-independent interface
        to the timing services needed by the RTS. Itimer.{c,h} +
        win32/Ticker.{c,h} defines the OS-specific services that
        creates/destroys a timer.
      - For win32 plats, drop the long-standing use of the 'multimedia'
        API timers and implement the ticking service ourselves. Simpler
        and more flexible.
      - Select.c is now solely for platforms that use select() to handle
        non-blocking I/O & thread delays. win32/AwaitEvent.c provides
        the same API on the Win32 side.
      - support threadDelay on win32 platforms via worker threads.
      
      Not yet compiled up on non-win32 platforms; will do once checked in.
      557947d3
  6. 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
  7. 18 Jul, 2002 1 commit
  8. 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
  9. 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
  10. 14 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-14 13:40:07 by sewardj] · bc5c8021
      sewardj authored
      Change the story about POSIX headers in C compilation.
      
      Until now, all C code in the RTS and library cbits has by default been
      compiled with settings for POSIXness enabled, that is:
         #define _POSIX_SOURCE   1
         #define _POSIX_C_SOURCE 199309L
         #define _ISOC9X_SOURCE
      If you wanted to negate this, you'd have to define NON_POSIX_SOURCE
      before including headers.
      
      This scheme has some bad effects:
      
      * It means that ccall-unfoldings exported via interfaces from a
        module compiled with -DNON_POSIX_SOURCE may not compile when
        imported into a module which does not -DNON_POSIX_SOURCE.
      
      * It overlaps with the feature tests we do with autoconf.
      
      * It seems to have caused borkage in the Solaris builds for some
        considerable period of time.
      
      The New Way is:
      
      * The default changes to not-being-in-Posix mode.
      
      * If you want to force a C file into Posix mode, #include as
        the **first** include the new file ghc/includes/PosixSource.h.
        Most of the RTS C sources have this include now.
      
      * NON_POSIX_SOURCE is almost totally expunged.  Unfortunately
        we have to retain some vestiges of it in ghc/compiler so that
        modules compiled via C on Solaris using older compilers don't
        break.
      bc5c8021
  11. 03 Apr, 2000 1 commit
  12. 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
  13. 04 Aug, 1999 1 commit
  14. 05 Feb, 1999 1 commit
  15. 02 Dec, 1998 1 commit