1. 05 Sep, 2010 1 commit
    • Ian Lynagh's avatar
      Don't set visibility on Windows · a96a7536
      Ian Lynagh authored
      With gcc 4.5.0-1, using visibility hidden gives:
          error: visibility attribute not supported in this configuration; ignored
      a96a7536
  2. 27 Aug, 2010 1 commit
  3. 26 Aug, 2010 1 commit
  4. 24 Aug, 2010 2 commits
    • 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
    • Simon Marlow's avatar
      da6d4885
  5. 23 Aug, 2010 1 commit
    • Simon Marlow's avatar
      Add a couple of missing tests for EAGER_BLACKHOLE · fd316eba
      Simon Marlow authored
      This was leading to looping and excessive allocation, when the
      computation should have just blocked on the black hole.  
      
      Reported by Christian Höner zu Siederdissen <choener@tbi.univie.ac.at>
      on glasgow-haskell-users.
      fd316eba
  6. 18 Jul, 2010 1 commit
    • marcotmarcot's avatar
      Don't check for swept blocks in -DS. · eff182c3
      marcotmarcot authored
      The checkHeap function assumed the allocated part of the block contained only
      alive objects and slops.  This was not true for blocks that are collected using
      mark sweep.  The code in this patch skip the test for this kind of blocks.
      eff182c3
  7. 17 Aug, 2010 1 commit
  8. 13 Aug, 2010 1 commit
  9. 10 Aug, 2010 1 commit
  10. 24 Jul, 2010 1 commit
  11. 05 Aug, 2010 2 commits
  12. 04 Aug, 2010 1 commit
  13. 01 Aug, 2010 1 commit
  14. 20 Jul, 2010 1 commit
    • pgj's avatar
      Add thread affinity support for FreeBSD · 13346da2
      pgj authored
      - Implement missing functions for setting thread affinity and getting real
        number of processors.
      - It is available starting from 7.1-RELEASE, which includes a native support
        for managing CPU sets.
      - Add __BSD_VISIBLE, since it is required for certain types to be visible in
        addition to POSIX & C99. 
      13346da2
  15. 29 Jul, 2010 1 commit
    • Ian Lynagh's avatar
      Disable symbol visibility pragmas for FreeBSD · 28c2bbb0
      Ian Lynagh authored
      Do not use GCC pragmas for controlling visibility, because it causes
      "undefined reference" errors at link-time.  The true reasons are
      unknown, however FreeBSD 8.x includes GCC 4.2.1 in the base system,
      which might be buggy. 
      28c2bbb0
  16. 28 Jul, 2010 1 commit
  17. 23 Jul, 2010 2 commits
  18. 20 Jul, 2010 1 commit
  19. 16 Jul, 2010 1 commit
    • Simon Marlow's avatar
      Use a separate mutex to protect all_tasks, avoiding a lock-order-reversal · ed301949
      Simon Marlow authored
      In GHC 6.12.x I found a rare deadlock caused by this
      lock-order-reversal:
      
      AQ cap->lock
        startWorkerTask
          newTask
            AQ sched_mutex
      
      scheduleCheckBlackHoles
        AQ sched_mutex
         unblockOne_
          wakeupThreadOnCapabilty
            AQ cap->lock
      
      so sched_mutex and cap->lock are taken in a different order in two
      places.
      
      This doesn't happen in the HEAD because we don't have
      scheduleCheckBlackHoles, but I thought it would be prudent to make
      this less likely to happen in the future by using a different mutex in
      newTask.  We can clearly see that the all_tasks mutex cannot be
      involved in a deadlock, becasue we never call anything else while
      holding it.
      ed301949
  20. 17 Jul, 2010 1 commit
  21. 16 Jul, 2010 2 commits
  22. 13 Jul, 2010 1 commit
  23. 08 Jul, 2010 2 commits
    • Simon Marlow's avatar
      New asynchronous exception control API (ghc parts) · ad3b79d2
      Simon Marlow authored
      As discussed on the libraries/haskell-cafe mailing lists
        http://www.haskell.org/pipermail/libraries/2010-April/013420.html
      
      This is a replacement for block/unblock in the asychronous exceptions
      API to fix a problem whereby a function could unblock asynchronous
      exceptions even if called within a blocked context.
      
      The new terminology is "mask" rather than "block" (to avoid confusion
      due to overloaded meanings of the latter).
      
      In GHC, we changed the names of some primops:
      
        blockAsyncExceptions#   -> maskAsyncExceptions#
        unblockAsyncExceptions# -> unmaskAsyncExceptions#
        asyncExceptionsBlocked# -> getMaskingState#
      
      and added one new primop:
      
        maskUninterruptible#
      
      See the accompanying patch to libraries/base for the API changes.
      ad3b79d2
    • Simon Marlow's avatar
      Win32 getProcessElapsedTime: use a higher-resolution time source · 1fb0f13a
      Simon Marlow authored
      QueryPerformanceCounter() on Windows gives much better resolution than
      GetSystemTimeAsFileTime().
      1fb0f13a
  24. 05 Jul, 2010 1 commit
    • Simon Marlow's avatar
      Disable dynamic linking optimisations on OS X · 062aa8af
      Simon Marlow authored
      To improve performance of the RTS when dynamically linked on x86, I
      previously disabled -fPIC for certain critical modules (the GC, and a
      few others).  However, build reports suggest that the dynamic linker
      on OS X doesn't like this, so I'm disabling this optimsation on that
      platform.
      062aa8af
  25. 01 Jul, 2010 1 commit
  26. 28 Jun, 2010 1 commit
  27. 24 Jun, 2010 4 commits
  28. 22 Jun, 2010 1 commit
    • dmp@rice.edu's avatar
      Add support for collecting PAPI native events · d4942f78
      dmp@rice.edu authored
      This patch extends the PAPI support in the RTS to allow collection of native
      events. PAPI can collect data for native events that are exposed by the
      hardware beyond the PAPI present events. The native events supported on your
      hardware can found by using the papi_native_avail tool.
      
      The RTS already allows users to specify PAPI preset events from the command
      line. This patch extends that support to allow users to specify native events.
      The changes needed are:
      
      1) New option (#) for the RTS PAPI flag for native events. For example, to
         collect the native event 0x40000000, use ./a.out +RTS -a#0x40000000 -sstderr
      
      2) Update the PAPI_FLAGS struct to store whether the user specified event is a
         papi preset or a native event
      
      3) Update init_countable_events function to add the native events after parsing
         the event code and decoding the name using PAPI_event_code_to_name
      d4942f78
  29. 20 Jun, 2010 1 commit
  30. 19 Jun, 2010 2 commits
  31. 01 Jan, 2010 1 commit