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. 30 Mar, 2011 1 commit
  2. 07 Jan, 2011 1 commit
  3. 24 Aug, 2010 1 commit
    • Simon Marlow's avatar
      Remove the debugging memory allocator - valgrind does a better job · ea0bfdad
      Simon Marlow authored
      I got fed up with the constant bogus output from the debugging memory
      allocator in RtsUtils.c.  One problem is that we allocate memory in
      constructors that then isn't tracked, because the debugging allocator
      hasn't been initialised yet.
      
      The bigger problem is that for a given piece of leaking memory it's
      impossible to find out where it was allocated; however Valgrind gives
      output like this:
      
      ==6967== 8 bytes in 1 blocks are still reachable in loss record 1 of 7
      ==6967==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
      ==6967==    by 0x4C28522: realloc (vg_replace_malloc.c:525)
      ==6967==    by 0x6745E9: stgReallocBytes (RtsUtils.c:213)
      ==6967==    by 0x68D812: setHeapAlloced (MBlock.c:91)
      ==6967==    by 0x68D8E2: markHeapAlloced (MBlock.c:116)
      ==6967==    by 0x68DB56: getMBlocks (MBlock.c:240)
      ==6967==    by 0x684F55: alloc_mega_group (BlockAlloc.c:305)
      ==6967==    by 0x6850C8: allocGroup (BlockAlloc.c:358)
      ==6967==    by 0x69484F: allocNursery (Storage.c:390)
      ==6967==    by 0x694ABD: allocNurseries (Storage.c:436)
      ==6967==    by 0x6944F2: initStorage (Storage.c:217)
      ==6967==    by 0x673E3C: hs_init (RtsStartup.c:160)
      
      which tells us exactly what the leaking bit of memory is.  So I don't
      think we need our own debugging allocator.
      ea0bfdad
  4. 28 Jun, 2010 1 commit
  5. 27 Jan, 2010 2 commits
  6. 22 Jan, 2010 1 commit
    • Simon Marlow's avatar
      Add some missing getStablePtr()s for CAFs that the RTS refers to · 849ce0c7
      Simon Marlow authored
      A recent patch ("Refactor CoreArity a bit") changed the arity of
      GHC.Conc.runSparks such that it became a CAF, and the RTS was not
      explicitly retaining it, which led to a crash when the CAF got GC'd.
      While fixing this I found a couple of other closures that the RTS
      refers to which weren't getting the correct CAF treatment.
      849ce0c7
  7. 16 Dec, 2009 1 commit
    • howard_b_golden@yahoo.com's avatar
      FIX #2615 (linker scripts in .so files) · e020e387
      howard_b_golden@yahoo.com authored
      This patch does not apply to Windows. It only applies to systems with
      ELF binaries.
      
      This is a patch to rts/Linker.c to recognize linker scripts in .so
      files and find the real target .so shared library for loading.
      e020e387
  8. 12 Dec, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Expose all EventLog events as DTrace probes · 015d3d46
      chak@cse.unsw.edu.au. authored
      - Defines a DTrace provider, called 'HaskellEvent', that provides a probe
        for every event of the eventlog framework.
      - In contrast to the original eventlog, the DTrace probes are available in
        all flavours of the runtime system (DTrace probes have virtually no
        overhead if not enabled); when -DTRACING is defined both the regular
        event log as well as DTrace probes can be used.
      - Currently, Mac OS X only.  User-space DTrace probes are implemented
        differently on Mac OS X than in the original DTrace implementation.
        Nevertheless, it shouldn't be too hard to enable these probes on other
        platforms, too.
      - Documentation is at http://hackage.haskell.org/trac/ghc/wiki/DTrace
      015d3d46
  9. 01 Dec, 2009 1 commit
  10. 14 Nov, 2009 1 commit
  11. 29 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Unify event logging and debug tracing. · a5288c55
      Simon Marlow authored
        - tracing facilities are now enabled with -DTRACING, and -DDEBUG
          additionally enables debug-tracing.  -DEVENTLOG has been
          removed.
      
        - -debug now implies -eventlog
      
        - events can be printed to stderr instead of being sent to the
          binary .eventlog file by adding +RTS -v (which is implied by the
          +RTS -Dx options).
      
        - -Dx debug messages can be sent to the binary .eventlog file
          by adding +RTS -l.  This should help debugging by reducing
          the impact of debug tracing on execution time.
      
        - Various debug messages that duplicated the information in events
          have been removed.
      a5288c55
  12. 30 Aug, 2009 1 commit
  13. 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.
      
       - Vario...
      a2a67cd5
  14. 29 May, 2009 1 commit
  15. 04 Jun, 2009 1 commit
  16. 02 Jun, 2009 1 commit
  17. 23 Apr, 2009 1 commit
  18. 17 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Add fast event logging · 8b18faef
      Simon Marlow authored
      Generate binary log files from the RTS containing a log of runtime
      events with timestamps.  The log file can be visualised in various
      ways, for investigating runtime behaviour and debugging performance
      problems.  See for example the forthcoming ThreadScope viewer.
      
      New GHC option:
      
        -eventlog   (link-time option) Enables event logging.
      
        +RTS -l     (runtime option) Generates <prog>.eventlog with
                    the binary event information.
      
      This replaces some of the tracing machinery we already had in the RTS:
      e.g. +RTS -vg  for GC tracing (we should do this using the new event
      logging instead).
      
      Event logging has almost no runtime cost when it isn't enabled, though
      in the future we might add more fine-grained events and this might
      change; hence having a link-time option and compiling a separate
      version of the RTS for event logging.  There's a small runtime cost
      for enabling event-logging, for most programs it shouldn't make much
      difference.
      
      (Todo: docs)
      8b18faef
  19. 19 Feb, 2009 1 commit
    • Simon Marlow's avatar
      Rewrite of signal-handling (ghc patch; see also base and unix patches) · 7ed3f755
      Simon Marlow authored
      The API is the same (for now).  The new implementation has the
      capability to define signal handlers that have access to the siginfo
      of the signal (#592), but this functionality is not exposed in this
      patch.
      
      #2451 is the ticket for the new API.
      
      The main purpose of bringing this in now is to fix race conditions in
      the old signal handling code (#2858).  Later we can enable the new
      API in the HEAD.
      
      Implementation differences:
      
       - More of the signal-handling is moved into Haskell.  We store the
         table of signal handlers in an MVar, rather than having a table of
         StablePtrs in the RTS.
      
       - In the threaded RTS, the siginfo of the signal is passed down the
         pipe to the IO manager thread, which manages the business of
         starting up new signal handler threads.  In the non-threaded RTS,
         the siginfo of caught signals is stored in the RTS, and the
         scheduler starts new signal handler threads.
      7ed3f755
  20. 10 Dec, 2008 1 commit
  21. 01 Oct, 2008 1 commit
  22. 02 Sep, 2008 1 commit
  23. 09 Jul, 2008 1 commit
    • Simon Marlow's avatar
      FIX part of #2301, and #1619 · addff19a
      Simon Marlow authored
      2301: Control-C now causes the new exception (AsyncException
      UserInterrupt) to be raised in the main thread.  The signal handler
      is set up by GHC.TopHandler.runMainIO, and can be overriden in the
      usual way by installing a new signal handler.  The advantage is that
      now all programs will get a chance to clean up on ^C.
      
      When UserInterrupt is caught by the topmost handler, we now exit the
      program via kill(getpid(),SIGINT), which tells the parent process that
      we exited as a result of ^C, so the parent can take appropriate action
      (it might want to exit too, for example).
      
      One subtlety is that we have to use a weak reference to the ThreadId
      for the main thread, so that the signal handler doesn't prevent the
      main thread from being subject to deadlock detection.
      
      1619: we now ignore SIGPIPE by default.  Although POSIX says that a
      SIGPIPE should terminate the process by default, I wonder if this
      decision was made because many C applications failed to check the exit
      code from write().  In Haskell a failed write due to a closed pipe
      will generate an exception anyway, so the main difference is that we
      now get a useful error message instead of silent program termination.
      See #1619 for more discussion.
      addff19a
  24. 16 Apr, 2008 1 commit
  25. 20 Nov, 2007 1 commit
    • simonmar@microsoft.com's avatar
      improvements to PAPI support · 8db56c86
      simonmar@microsoft.com authored
      - major (multithreaded) GC is measured separately from minor GC
      - events to measure can now be specified on the command line, e.g
           prog +RTS -a+PAPI_TOT_CYC
      8db56c86
  26. 31 Oct, 2007 1 commit
  27. 29 May, 2008 1 commit
  28. 12 May, 2008 1 commit
  29. 28 Feb, 2008 1 commit
    • Simon Marlow's avatar
      Enable -prof -threaded (#886) · 50c4d039
      Simon Marlow authored
      It turns out that -prof -threaded works (modulo some small changes),
      because all the data structures used in profiling are only accessed by
      one thread at a time, at long as we don't use +RTS -N2 or higher.  So
      this patch enables the use of -prof -threaded, but an error is given
      if you ask for more than one CPU with +RTS -N.
      50c4d039
  30. 20 Nov, 2007 1 commit
    • Simon Marlow's avatar
      Move file locking into the RTS, fixing #629, #1109 · 1d026619
      Simon Marlow authored
      File locking (of the Haskell 98 variety) was previously done using a
      static table with linear search, which had two problems: the array had
      a fixed size and was sometimes too small (#1109), and performance of
      lockFile/unlockFile was suboptimal due to the linear search.
      Also the algorithm failed to count readers as required by Haskell 98
      (#629).
      
      Now it's done using a hash table (provided by the RTS).  Furthermore I
      avoided the extra fstat() for every open file by passing the dev_t and
      ino_t into lockFile.  This and the improvements to the locking
      algorithm result in a healthy 20% or so performance increase for
      opening/closing files (see openFile008 test).
      1d026619
  31. 03 Sep, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1623: disable the timer signal when the system is idle (threaded RTS only) · 8d71be7c
      Simon Marlow authored
      Having a timer signal go off regularly is bad for power consumption,
      and generally bad practice anyway (it means the app cannot be
      completely swapped out, for example).  Fortunately the threaded RTS
      already had a way to detect when the system was idle, so that it can
      trigger a GC and thereby find deadlocks.  After performing the GC, we
      now turn off timer signals, and re-enable them again just before
      running any Haskell code.
      8d71be7c
  32. 24 Aug, 2007 1 commit
  33. 17 Aug, 2007 1 commit
  34. 25 Jul, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1177, partially at least. · eb5791fe
      Simon Marlow authored
      Now we don't wait for outstanding IO requests when shutting down at
      program exit time, but we still wait when shutting down a DLL (via
      hs_exit()).  There ought to be a better way to do this, but
      terminating the threads forcibly is not a good idea (it never is: the
      thread might be holding a mutex when it dies, for example).
      
      I plan to add some docs to the user guide to describe how to shut
      down a DLL properly.
      eb5791fe
  35. 24 Jul, 2007 1 commit
    • Simon Marlow's avatar
      hs_exit()/shutdownHaskell(): wait for outstanding foreign calls to complete before returning · 681aad99
      Simon Marlow authored
      This is pertinent to #1177.  When shutting down a DLL, we need to be
      sure that there are no OS threads that can return to the code that we
      are about to unload, and previously the threaded RTS was unsafe in
      this respect.
      
      When exiting a standalone program we don't have to be quite so
      paranoid: all the code will disappear at the same time as any running
      threads.  Happily exiting a program happens via a different path:
      shutdownHaskellAndExit().  If we're about to exit(), then there's no
      need to wait for foreign calls to complete.
      681aad99
  36. 17 Jul, 2007 1 commit
  37. 01 Jun, 2007 1 commit
  38. 08 May, 2007 1 commit
  39. 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