1. 20 May, 2009 1 commit
  2. 23 Apr, 2009 1 commit
  3. 30 Mar, 2009 1 commit
  4. 13 Mar, 2009 1 commit
  5. 06 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Partial fix for #2917 · 1b62aece
      Simon Marlow authored
       - add newAlignedPinnedByteArray# for allocating pinned BAs with
         arbitrary alignment
      
       - the old newPinnedByteArray# now aligns to 16 bytes
      
      Foreign.alloca will use newAlignedPinnedByteArray#, and so might end
      up wasting less space than before (we used to align to 8 by default).
      Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte
      aligned memory, which is enough to avoid problems with SSE
      instructions on x86, for example.
      
      There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes,
      but would have failed if the header was not a multiple of 8
      (fortunately it always was, even with profiling).  Also we
      occasionally wasted some space unnecessarily due to alignment in
      allocatePinned().
      
      I haven't done anything about Foreign.malloc/mallocBytes, which will
      give you the same alignment guarantees as malloc() (8 bytes on
      Linux/x86 here).
      1b62aece
  6. 19 Feb, 2009 1 commit
  7. 27 Jan, 2009 1 commit
  8. 08 Jan, 2009 1 commit
  9. 10 Dec, 2008 2 commits
  10. 21 Nov, 2008 2 commits
  11. 20 Nov, 2008 2 commits
  12. 19 Nov, 2008 1 commit
  13. 18 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Add optional eager black-holing, with new flag -feager-blackholing · d600bf7a
      Simon Marlow authored
      Eager blackholing can improve parallel performance by reducing the
      chances that two threads perform the same computation.  However, it
      has a cost: one extra memory write per thunk entry.  
      
      To get the best results, any code which may be executed in parallel
      should be compiled with eager blackholing turned on.  But since
      there's a cost for sequential code, we make it optional and turn it on
      for the parallel package only.  It might be a good idea to compile
      applications (or modules) with parallel code in with
      -feager-blackholing.
      
      ToDo: document -feager-blackholing.
      d600bf7a
  14. 17 Nov, 2008 2 commits
    • Simon Marlow's avatar
      fix compile breakage on Windows · 27f66c28
      Simon Marlow authored
      27f66c28
    • Simon Marlow's avatar
      Attempt to fix #2512 and #2063; add +RTS -xm<address> -RTS option · 11f6f411
      Simon Marlow authored
      On x86_64, the RTS needs to allocate memory in the low 2Gb of the
      address space.  On Linux we can do this with MAP_32BIT, but sometimes
      this doesn't work (#2512) and other OSs don't support it at all
      (#2063).  So to work around this:
      
        - Try MAP_32BIT first, if available.
      
        - Otherwise, try allocating memory from a fixed address (by default
          1Gb)
      
        - We now provide an option to configure the address to allocate
          from.  This allows a workaround on machines where the default
          breaks, and also provides a way for people to test workarounds
          that we can incorporate in future releases.
      11f6f411
  15. 13 Nov, 2008 1 commit
  16. 12 Nov, 2008 1 commit
  17. 06 Nov, 2008 1 commit
  18. 13 Oct, 2008 1 commit
  19. 10 Oct, 2008 1 commit
  20. 16 Sep, 2008 1 commit
  21. 15 Sep, 2008 1 commit
    • Simon Marlow's avatar
      Stop using mremap() to allocate space for trampolines · bf7e78fa
      Simon Marlow authored
      This was causing problems because sometimes mremap() moved the memory
      we had allocated from the low 2Gb to above the 2Gb boundary, causing
      some linkages to fail.  There's no MAP_32BIT flag to mremap().
      
      So now we just use mmap(MAP_ANON|MAP_32BIT) to allocated space for the
      trampolines.  People without MAP_32BIT (eg. *BSD) will still have to
      do something else here, such as allocating memory from a fixed
      address; so I've made it slightly easier for those guys, but there's
      still work to do (#2063).
      
      One solution (that Simon PJ is advocating) is to turn on -fPIC by
      default on x86-64.  This is a good solution as it removes the need for
      MAP_32BIT, but doesn't work with -fvia-C, so probably this is for
      later.
      bf7e78fa
  22. 08 Sep, 2008 1 commit
  23. 03 Sep, 2008 1 commit
    • Simon Marlow's avatar
      Windows: print an error message in addDLL · b9110541
      Simon Marlow authored
      Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
      isn't really a proper fix, but it'll help in some cases).
      And I tidied up the error message for a DLL load failure, though it's
      still a bit of a mess because addDLL is supposed to return a (static)
      string with the error message, but this isn't possible on Windows.
      b9110541
  24. 04 Aug, 2008 3 commits
  25. 30 Jul, 2008 2 commits
  26. 24 Jul, 2008 2 commits
  27. 14 Jul, 2008 1 commit
  28. 10 Jul, 2008 1 commit
  29. 09 Jul, 2008 2 commits
    • Simon Marlow's avatar
      fb8c1b80
    • 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
  30. 14 Jun, 2008 1 commit
  31. 28 May, 2008 1 commit