1. 08 May, 2012 1 commit
  2. 27 Apr, 2012 1 commit
  3. 27 Feb, 2012 1 commit
  4. 06 Dec, 2011 1 commit
    • Simon Marlow's avatar
      Make forkProcess work with +RTS -N · 8b75acd3
      Simon Marlow authored
      Consider this experimental for the time being.  There are a lot of
      things that could go wrong, but I've verified that at least it works
      on the test cases we have.
      
      I also did some API cleanups while I was here.  Previously we had:
      
      Capability * rts_eval (Capability *cap, HaskellObj p, /*out*/HaskellObj *ret);
      
      but this API is particularly error-prone: if you forget to discard the
      Capability * you passed in and use the return value instead, then
      you're in for subtle bugs with +RTS -N later on.  So I changed all
      these functions to this form:
      
      void rts_eval (/* inout */ Capability **cap,
                     /* in    */ HaskellObj p,
                     /* out */   HaskellObj *ret)
      
      It's much harder to use this version incorrectly, because you have to
      pass the Capability in by reference.
      8b75acd3
  5. 24 Nov, 2011 1 commit
  6. 17 Nov, 2011 1 commit
  7. 16 Nov, 2011 2 commits
    • dterei's avatar
      Remove executable mode from some files · ed4252cf
      dterei authored
      ed4252cf
    • 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. 09 Nov, 2011 1 commit
  9. 08 Nov, 2011 1 commit
  10. 26 Oct, 2011 1 commit
  11. 12 Aug, 2011 1 commit
  12. 26 May, 2011 2 commits
  13. 25 May, 2011 1 commit
  14. 22 May, 2011 1 commit
  15. 18 May, 2011 1 commit
  16. 12 Apr, 2011 2 commits
    • Simon Marlow's avatar
      Change the way module initialisation is done (#3252, #4417) · a52ff761
      Simon Marlow authored
      Previously the code generator generated small code fragments labelled
      with __stginit_M for each module M, and these performed whatever
      initialisation was necessary for that module and recursively invoked
      the initialisation functions for imported modules.  This appraoch had
      drawbacks:
      
       - FFI users had to call hs_add_root() to ensure the correct
         initialisation routines were called.  This is a non-standard,
         and ugly, API.
      
       - unless we were using -split-objs, the __stginit dependencies would
         entail linking the whole transitive closure of modules imported,
         whether they were actually used or not.  In an extreme case (#4387,
         #4417), a module from GHC might be imported for use in Template
         Haskell or an annotation, and that would force the whole of GHC to
         be needlessly linked into the final executable.
      
      So now instead we do our initialisation with C functions marked with
      __attribute__((constructor)), which are automatically invoked at
      program startup time (or DSO load-time).  The C initialisers are
      emitted into the stub.c file.  This means that every time we compile
      with -prof or -hpc, we now get a stub file, but thanks to #3687 that
      is now invisible to the user.
      
      There are some refactorings in the RTS (particularly for HPC) to
      handle the fact that initialisers now get run earlier than they did
      before.
      
      The __stginit symbols are still generated, and the hs_add_root()
      function still exists (but does nothing), for backwards compatibility.
      a52ff761
    • Simon Marlow's avatar
      Cleanup sweep and fix a bug in RTS flag processing. · 5463b55b
      Simon Marlow authored
      This code has accumulated a great deal of cruft over the years, this
      pass cleans up a lot of the surrounding cruft but leaves the actual
      argument processing alone - so there's still more that could be done.
      
      Bug fixed:
      
        - ghc_rts_opts should not be subject to the --rtsopts setting.  If
          the programmer explicitly declares options with ghc_rts_opts, they
          shouldn't also have to accept command-line RTS options to make them
          work.
      5463b55b
  17. 30 Mar, 2011 1 commit
  18. 07 Jan, 2011 1 commit
  19. 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
  20. 28 Jun, 2010 1 commit
  21. 27 Jan, 2010 2 commits
  22. 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
  23. 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
  24. 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
  25. 01 Dec, 2009 1 commit
  26. 14 Nov, 2009 1 commit
  27. 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
  28. 30 Aug, 2009 1 commit
  29. 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
  30. 29 May, 2009 1 commit
  31. 04 Jun, 2009 1 commit
  32. 02 Jun, 2009 1 commit
  33. 23 Apr, 2009 1 commit
  34. 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
  35. 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
  36. 10 Dec, 2008 1 commit