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. 26 Apr, 2012 3 commits
  2. 24 Apr, 2012 1 commit
  3. 19 Mar, 2012 1 commit
  4. 18 Mar, 2012 1 commit
  5. 15 Jan, 2012 1 commit
    • Ian Lynagh's avatar
      Fix a #define · 54121fff
      Ian Lynagh authored
      I don't think it was causing any problems, but
          TimeToUS(x+y)
      would have evaluated to
          x + (y / 1000)
      54121fff
  6. 25 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Time handling overhaul · 6b109851
      Simon Marlow authored
      Terminology cleanup: the type "Ticks" has been renamed "Time", which
      is an StgWord64 in units of TIME_RESOLUTION (currently nanoseconds).
      The terminology "tick" is now used consistently to mean the interval
      between timer signals.
      
      The ticker now always ticks in realtime (actually CLOCK_MONOTONIC if
      we have it).  Before it used CPU time in the non-threaded RTS and
      realtime in the threaded RTS, but I've discovered that the CPU timer
      has terrible resolution (at least on Linux) and isn't much use for
      profiling.  So now we always use realtime.  This should also fix
      
      The default tick interval is now 10ms, except when profiling where we
      drop it to 1ms.  This gives more accurate profiles without affecting
      runtime too much (<1%).
      
      Lots of cleanups - the resolution of Time is now in one place
      only (Rts.h) rather than having calculations that depend on the
      resolution scattered all over the RTS.  I hope I found them all.
      6b109851
  7. 16 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Generate the C main() function when linking a binary (fixes #5373) · 1df28a80
      Simon Marlow authored
      Rather than have main() be statically compiled as part of the RTS, we
      now generate it into the tiny C file that we compile when linking a
      binary.
      
      The main motivation is that we want to pass the settings for the
      -rtsotps and -with-rtsopts flags into the RTS, rather than relying on
      fragile linking semantics to override the defaults, which don't work
      with DLLs on Windows (#5373).  In order to do this, we need to extend
      the API for initialising the RTS, so now we have:
      
      void hs_init_ghc (int *argc, char **argv[],   // program arguments
                        RtsConfig rts_config);      // RTS configuration
      
      hs_init_ghc() can optionally be used instead of hs_init(), and allows
      passing in configuration options for the RTS.  RtsConfig is a struct,
      which currently has two fields:
      
      typedef struct {
          RtsOptsEnabledEnum rts_opts_enabled;
          const char *rts_opts;
      } RtsConfig;
      
      but might have more in the future.  There is a default value for the
      struct, defaultRtsConfig, the idea being that you start with this and
      override individual fields as necessary.
      
      In fact, main() was in a separate static library, libHSrtsmain.a.
      That's now gone.
      1df28a80
  8. 25 May, 2011 1 commit
  9. 14 May, 2011 1 commit
  10. 23 Nov, 2010 1 commit
  11. 17 Jun, 2010 1 commit
  12. 29 Mar, 2010 1 commit
    • Simon Marlow's avatar
      New implementation of BLACKHOLEs · 5d52d9b6
      Simon Marlow authored
      This replaces the global blackhole_queue with a clever scheme that
      enables us to queue up blocked threads on the closure that they are
      blocked on, while still avoiding atomic instructions in the common
      case.
      
      Advantages:
      
       - gets rid of a locked global data structure and some tricky GC code
         (replacing it with some per-thread data structures and different
         tricky GC code :)
      
       - wakeups are more prompt: parallel/concurrent performance should
         benefit.  I haven't seen anything dramatic in the parallel
         benchmarks so far, but a couple of threading benchmarks do improve
         a bit.
      
       - waking up a thread blocked on a blackhole is now O(1) (e.g. if
         it is the target of throwTo).
      
       - less sharing and better separation of Capabilities: communication
         is done with messages, the data structures are strictly owned by a
         Capability and cannot be modified except by sending messages.
      
       - this change will utlimately enable us to do more intelligent
         scheduling when threads block on each other.  This is what started
         off the whole thing, but it isn't done yet (#3838).
      
      I'll be documenting all this on the wiki in due course.
      5d52d9b6
  13. 27 Mar, 2010 1 commit
  14. 12 Sep, 2009 1 commit
  15. 09 Sep, 2009 1 commit
  16. 29 Aug, 2009 2 commits
  17. 25 Aug, 2009 1 commit
  18. 03 Aug, 2009 2 commits
  19. 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.
      
       - Various bits of dead code and declarations have been removed
      
       - More gcc warnings are turned on, and the RTS code is more
         warning-clean.
      
       - More source files #include "PosixSource.h", and hence only use
         standard POSIX (1003.1c-1995) interfaces.
      
      There is a lot more tidying up still to do, this is just the first
      pass.  I also intend to standardise the names for external RTS APIs
      (e.g use the rts_ prefix consistently), and declare the internal APIs
      as hidden for shared libraries.
      a2a67cd5
  20. 28 Jun, 2009 1 commit
  21. 29 Jul, 2009 1 commit
  22. 23 Jul, 2009 1 commit
  23. 13 Jun, 2009 2 commits
  24. 02 Jun, 2009 2 commits
  25. 16 Apr, 2008 1 commit
  26. 15 Feb, 2008 1 commit
  27. 14 Jun, 2008 1 commit
  28. 17 Apr, 2008 1 commit
  29. 02 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Do not #include external header files when compiling via C · c245355e
      Simon Marlow authored
      This has several advantages:
      
       - -fvia-C is consistent with -fasm with respect to FFI declarations:
         both bind to the ABI, not the API.
      
       - foreign calls can now be inlined freely across module boundaries, since
         a header file is not required when compiling the call.
      
       - bootstrapping via C will be more reliable, because this difference
         in behavour between the two backends has been removed.
      
      There is one disadvantage:
      
       - we get no checking by the C compiler that the FFI declaration
         is correct.
      
      So now, the c-includes field in a .cabal file is always ignored by
      GHC, as are header files specified in an FFI declaration.  This was
      previously the case only for -fasm compilations, now it is also the
      case for -fvia-C too.
      c245355e
  30. 25 Aug, 2007 1 commit
  31. 27 Jul, 2007 1 commit
    • Simon Marlow's avatar
      Pointer Tagging · 6015a94f
      Simon Marlow authored
        
      This patch implements pointer tagging as per our ICFP'07 paper "Faster
      laziness using dynamic pointer tagging".  It improves performance by
      10-15% for most workloads, including GHC itself.
      
      The original patches were by Alexey Rodriguez Yakushev
      <mrchebas@gmail.com>, with additions and improvements by me.  I've
      re-recorded the development as a single patch.
      
      The basic idea is this: we use the low 2 bits of a pointer to a heap
      object (3 bits on a 64-bit architecture) to encode some information
      about the object pointed to.  For a constructor, we encode the "tag"
      of the constructor (e.g. True vs. False), for a function closure its
      arity.  This enables some decisions to be made without dereferencing
      the pointer, which speeds up some common operations.  In particular it
      enables us to avoid costly indirect jumps in many cases.
      
      More information in the commentary:
      
      http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
      6015a94f
  32. 06 Jul, 2007 1 commit
  33. 24 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make ticky work, at least partly, on 64-bit machines · a01188d1
      simonpj@microsoft.com authored
      The ticky StgEntCounter structure was trying to be clever by using a
      fixed-width 32-bit field for the registeredp value.  But the code generators
      are not up to handling structures packed tightly like this (on a 64-bit
      architecture); result seg-fault on 64-bit.
      
      Really there should be some complaint from the code generators, not simply
      a seg fault.
      
      Anyway I switched to using native words for StgEntCounter fields, and
      now at least it works.
      a01188d1
  34. 07 Feb, 2007 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Lightweight ticky-ticky profiling · 5ddee764
      chevalier@alum.wellesley.edu authored
      The following changes restore ticky-ticky profiling to functionality
      from its formerly bit-rotted state. Sort of. (It got bit-rotted as part
      of the switch to the C-- back-end.)
      
      The way that ticky-ticky is supposed to work is documented in Section 5.7
      of the GHC manual (though the manual doesn't mention that it hasn't worked
      since sometime around 6.0, alas). Changes from this are as follows (which
      I'll document on the wiki):
      
      * In the past, you had to build all of the libraries with way=t in order to
      use ticky-ticky, because it entailed a different closure layout. No longer.
      You still need to do make way=t in rts/ in order to build the ticky RTS,
      but you should now be able to mix ticky and non-ticky modules.
      
      * Some of the counters that worked in the past aren't implemented yet.
      I was originally just trying to get entry counts to work, so those should
      be correct. The list of counters was never documented in the first place,
      so I hope it's not too much of a disaster that some don't appear anymore.
      Someday, someone (perhaps me) should document all the counters and what 
      they do. For now, all of the counters are either accurate (or at least as
      accurate as they always were), zero, or missing from the ticky profiling
      report altogether.
      
      This hasn't been particularly well-tested, but these changes shouldn't
      affect anything except when compiling with -fticky-ticky (famous last
      words...)
      
      Implementation details:
      
      I got rid of StgTicky.h, which in the past had the macros and declarations 
      for all of the ticky counters. Now, those macros are defined in Cmm.h.
      StgTicky.h was still there for inclusion in C code. Now, any remaining C
      code simply cannot call the ticky macros -- or rather, they do call those
      macros, but from the perspective of C code, they're defined as no-ops. 
      (This shouldn't be too big a problem.)
      
      I added a new file TickyCounter.h that has all the declarations for ticky
      counters, as well as dummy macros for use in C code. Someday, these 
      declarations should really be automatically generated, since they need
      to be kept consistent with the macros defined in Cmm.h.
      
      Other changes include getting rid of the header that was getting added to
      closures before, and getting rid of various code having to do with eager
      blackholing and permanent indirections (the changes under compiler/ 
      and rts/Updates.*).
      5ddee764