1. 06 Dec, 2016 1 commit
    • Simon Marlow's avatar
      Overhaul GC stats · 24e6594c
      Simon Marlow authored
      Summary:
      Visible API changes:
      
      * The C struct `GCDetails` gives the stats about a single GC.  This is
        passed to the `gcDone()` callback if one is set via the
        RtsConfig. (previously we just passed a collection of values, so this
        is more extensible, at the expense of breaking the existing API)
      
      * `RTSStats` gives cumulative stats since the start of the program,
        and includes the `GCDetails` for the most recent GC.  This struct
        can be obtained via `getRTSStats()` (the old `getGCStats()` has been
        removed, and `getGCStatsEnabled()` has been renamed to
        `getRTSStatsEnabled()`)
      
      Improvements:
      
      * The per-GC stats and cumulative stats are now cleanly separated.
      
      * Inside the RTS we have a top-level `RTSStats` struct to keep all our
        stats in, previously this was just a collection of strangely-named
        variables.  This struct is mostly just copied in `getRTSStats()`, so
        the implementation of that function is a lot shorter.
      
      * Types are more consistent.  We use a uint64_t byte count for all
        memory values, and Time for all time values.
      
      * Names are more consistent.  We use a suffix `_bytes` for all byte
        counts and `_ns` for all time values.
      
      * We now collect information about the amount of memory in large
        objects and compact objects in `GCDetails`. (the latter was the reason
        I started doing this patch but it seems to have ballooned a bit!)
      
      * I fixed a bug in the calculation of the elapsed MUT time, and added
        an ASSERT to stop the calculations going wrong in the future.
      
      For now I kept the Haskell API in `GHC.Stats` the same, by
      impedence-matching with the new API.  We could either break that API
      and make it match the C API more closely, or we could add a new API
      and deprecate the old one.  Opinions welcome.
      
      This stuff is very easy to get wrong, and it's hard to test.  Reviews
      welcome!
      
      Test Plan:
      manual testing
      validate
      
      Reviewers: bgamari, niteria, austin, ezyang, hvr, erikd, rwbarton, Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2756
      24e6594c
  2. 02 Dec, 2016 1 commit
    • Alexander Vershilov's avatar
      Install toplevel handler inside fork. · 895a131f
      Alexander Vershilov authored
      When rts is forked it doesn't update toplevel handler, so UserInterrupt
      exception is sent to Thread1 that doesn't exist in forked process.
      
      We install toplevel handler when fork so signal will be delivered to the
      new main thread.
      
      Fixes #12903
      
      Reviewers: simonmar, austin, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2770
      
      GHC Trac Issues: #12903
      895a131f
  3. 18 Nov, 2016 1 commit
    • Tamar Christina's avatar
      Add missing SMP symbols to RT linker. · 94d1221c
      Tamar Christina authored
      Summary:
      Add some missing symbols that we
      export from the public headers but forgot to include
      in the runtime linker's symbol table.
      
      This is a bit of a unsatifactory patch, since we have a bit of a
      cat and mouse game going. We should find a way to automate this.
      
      But I know of no good solutions at the moment that won't add all
      rts symbols (including those we don't have an extern declaration for.).
      
      So for now, just add the ones reported missing.
      
      Test Plan: inplace/bin/ghc-stage2.exe --interactive
      
      Reviewers: RyanGlScott, austin, erikd, simonmar, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2727
      
      GHC Trac Issues: #12846
      94d1221c
  4. 19 Oct, 2016 1 commit
  5. 01 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Added support for deprecated POSIX functions on Windows. · e5ecb201
      Tamar Christina authored
      Summary:
      With the introduction of 8.0.1 We've stopped supporting in GHCi
      the use of POSIX functions under their deprecated names on Windows.
      
      This to be compatible with object and libraries from the most
      popular compilers on the platform (Microsoft and Intel compilers).
      
      However this brings a confusing disparity between the compiled and
      interpreted behavior since MingW-W64 does support the deprecated names.
      
      Also It seems clear that package writers won't update their packages to
      properly support Windows. As such I have added redirects in the RTS
      for the deprecated functions as listed on
      
      https://msdn.microsoft.com/en-us/library/ms235384.aspx.
      
      This won't export the functions (as in, they won't be in the symbol table
      of compiled code for the RTS.) but we inject them into the symbol table
      of the dynamic linker at startup.
      
      Test Plan:
      ./validate
      and
      
      make test TEST="ffi017 ffi021"
      
      Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: RyanGlScott, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2500
      
      GHC Trac Issues: #12209, #12497, #12496
      e5ecb201
  6. 30 Aug, 2016 1 commit
    • mniip's avatar
      Tag pointers in interpreted constructors · a25bf267
      mniip authored
      Instead of stg_interp_constr_entry there are now 7 functions (one for
      each value of the tag bits) that tag the constructor pointer before
      returning. This is consistent with compiled constructors' entry code,
      and expectations that compiled code places on compiled constructors. The
      iserv protocol is extended with an extra field that explains what
      pointer tag the constructor should use.
      
      Test Plan: Added tests for #12523
      
      Reviewers: erikd, bgamari, hvr, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: osa1, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D2473
      
      GHC Trac Issues: #12523
      a25bf267
  7. 13 Aug, 2016 1 commit
    • Erik de Castro Lopo's avatar
      Fix GHCi perf-llvm build on x86_64 · bd0c3106
      Erik de Castro Lopo authored
      With BuildFlavour set to `perf-llvm`, GHCi would fail as soon as it
      was run with:
      
        ghc-stage2: .../ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o:
        unknown symbol `__udivti3'
        ghc-stage2: unable to load package `ghc-prim-0.5.0.0'
      
      Fix this by adding `__udivti3` and `__umodti3` to RtsSymbols.c.
      
      Test Plan: Validate
      
      Reviewers: simonmar, austin, bgamari, Phyx, trofi
      
      Reviewed By: Phyx, trofi
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2449
      
      GHC Trac Issues: #11981
      bd0c3106
  8. 20 Jul, 2016 1 commit
    • gcampax's avatar
      Compact Regions · cf989ffe
      gcampax authored
      This brings in initial support for compact regions, as described in the
      ICFP 2015 paper "Efficient Communication and Collection with Compact
      Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni
      Campagna.
      
      Some things may change before the 8.2 release, but I (Simon M.) wanted
      to get the main patch committed so that we can iterate.
      
      What documentation there is is in the Data.Compact module in the new
      compact package.  We'll need to extend and polish the documentation
      before the release.
      
      Test Plan:
      validate
      (new test cases included)
      
      Reviewers: ezyang, simonmar, hvr, bgamari, austin
      
      Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1264
      
      GHC Trac Issues: #11493
      cf989ffe
  9. 04 Jun, 2016 1 commit
  10. 18 May, 2016 2 commits
    • Ben Gamari's avatar
      rts: Add isPinnedByteArray# primop · 310371ff
      Ben Gamari authored
      Adds a primitive operation to determine whether a particular
      `MutableByteArray#` is backed by a pinned buffer.
      
      Test Plan: Validate with included testcase
      
      Reviewers: austin, simonmar
      
      Reviewed By: austin, simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2217
      
      GHC Trac Issues: #12059
      310371ff
    • mlen's avatar
      Fix histograms for ticky code · f0f0ac85
      mlen authored
      This patch fixes Cmm generation required to produce histograms when
      compiling with -ticky flag, strips dead code from rts/Ticky.c and
      reworks it to use a shared constant in both C and Haskell code.
      
      Fixes #8308.
      
      Test Plan: T8308
      
      Reviewers: jstolarek, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: mpickering, simonpj, bgamari, mlen, thomie, jstolarek
      
      Differential Revision: https://phabricator.haskell.org/D931
      
      GHC Trac Issues: #8308
      f0f0ac85
  11. 10 Apr, 2016 1 commit
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 90538d86
      Tamar Christina authored
      The Runtime Linker is currently eagerly loading all object files on all
      platforms which do not use the system linker for `GHCi`.
      
      The problem with this approach is that it requires all symbols to be
      found.  Even those of functions never used/called. This makes the number
      of libraries required to link things like `mingwex` quite high.
      
      To work around this the `rts` was relying on a trick. It itself was
      compiled with `MingW64-w`'s `GCC`. So it was already linked against
      `mingwex`.  As such, it re-exported the symbols from itself.
      
      While this worked it made it impossible to link against `mingwex` in
      user libraries. And with this means no `C99` code could ever run in
      `GHCi` on Windows without having the required symbols re-exported from
      the rts.
      
      Consequently this rules out a large number of packages on Windows.
      SDL2, HMatrix etc.
      
      After talking with @rwbarton I have taken the approach of loading entire
      object files when a symbol is needed instead of doing the dependency
      tracking on a per symbol basis. This is a lot less fragile and a lot
      less complicated to implement.
      
      The changes come down to the following steps:
      
      1) modify the linker to and introduce a new state for ObjectCode:
         `Needed`.  A Needed object is one that is required for the linking to
         succeed.  The initial set consists of all Object files passed as
         arguments to the link.
      
      2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
         This means we know where we would load the symbols,
         but haven't actually done so.
      
      3) Mark any `ObjectCode` belonging to `.o` passed as argument
         as required: ObjectState `NEEDED`.
      
      4) During `Resolve` object calls, mark all `ObjectCode`
         containing the required symbols as `NEEDED`
      
      5) During `lookupSymbol` lookups, (which is called from `linkExpr`
         and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
         `ObjectCode` then load the `ObjectCode` on demand and return the
         address of the symbol. Otherwise produce an unresolved symbols error
         as expected.
      
      6) On `unloadObj` we then change the state of the object and remove
         it's symbols from the `reqSymHash` table so it can be reloaded.
      
      This change affects all platforms and OSes which use the runtime linker.
      It seems there are no real perf tests for `GHCi`, but performance
      shouldn't be impacted much. We gain a lot of time not loading all `obj`
      files, and we lose some time in `lookupSymbol` when we're finding
      sections that have to be loaded. The actual finding itself is O(1)
      (Assuming the hashtnl is perfect)
      
      It also consumes slighly more memory as instead of storing just the
      address of a symbol I also store some other information, like if the
      symbol is weak or not.
      
      This change will break any packages relying on renamed POSIX functions
      that were re-named and re-exported by the rts. Any packages following
      the proper naming for functions as found on MSDN will work fine.
      
      Test Plan: ./validate on all platforms which use the Runtime linker.
      
      Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr
      
      Reviewed By: erikd
      
      Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
                   rwbarton, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1805
      
      GHC Trac Issues: #11223
      90538d86
  12. 23 Dec, 2015 1 commit
  13. 21 Dec, 2015 2 commits
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      Summary:
      Breakpoints become SCCs, so we have detailed call-stack info for
      interpreted code.  Currently this only works when GHC is compiled with
      -prof, but D1562 (Remote GHCi) removes this constraint so that in the
      future call stacks will be available without building your own GHCi.
      
      How can you get a stack trace?
      
      * programmatically: GHC.Stack.currentCallStack
      * I've added an experimental :where command that shows the stack when
        stopped at a breakpoint
      * `error` attaches a call stack automatically, although since calls to
        `error` are often lifted out to the top level, this is less useful
        than it might be (ImplicitParams still works though).
      * Later we might attach call stacks to all exceptions
      
      Other related changes in this diff:
      
      * I reduced the number of places that get ticks attached for
        breakpoints.  In particular there was a breakpoint around the whole
        declaration, which was often redundant because it bound no variables.
        This reduces clutter in the stack traces and speeds up compilation.
      
      * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
        other small cleanups
      
      Test Plan: validate
      
      Reviewers: ezyang, bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1595
      
      GHC Trac Issues: #11047
      c8c44fd9
    • dolio's avatar
      Implement phase 1 of expanded Floating · 6457903e
      dolio authored
      - This part of the proposal is to add log1p, expm1, log1pexp and
        log1mexp to the Floating class, and export the full Floating class
        from Numeric
      
      Reviewers: ekmett, #core_libraries_committee, bgamari, hvr, austin
      
      Reviewed By: ekmett, #core_libraries_committee, bgamari
      
      Subscribers: Phyx, RyanGlScott, ekmett, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1605
      
      GHC Trac Issues: #11166
      6457903e
  14. 23 Nov, 2015 3 commits
  15. 17 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Fix archive loading on Windows by the runtime loader · acce37f3
      Tamar Christina authored
      The runtime loader is unable to find archive files `.a` shipping
      with the inplace `GCC`.
      
      It seems the issue is caused by `findArchive` being unable to
      find any archives that are shipped using the in-place `GCC`.
      
      - It works on Linux because `findArchive` would search
        the standard Linux include path.
      - It works during compilation because `GCC` can find it's own libraries
        (we explicitly tell it where to look for libraries using the `gcc`
        wrapper around `realgcc`)
      
      So fixing the issue means using `searchForLibUsingGcc` in `findArchive`
      as well, which will then find the correct file.
      
      The reason for the error as it is, is because if we can't locate the
      library using any of the methods we have, we assume it is a system dll,
      or something on the system search path.  e.g. if trying to load
      `kernel32.dll`.
      
      There is a slight issue in that the `GHCi` code (incorrectly) favors
      `static archives` over `dynamic` ones
      
      ```
      findDll        `orElse`
      findArchive    `orElse`
      tryGcc         `orElse`
      tryGccPrefixed `orElse`
      assumeDll
      ```
      This has the unwanted effect of when `kernel32` is specified as a lib,
      it will try to load `kernel32.a` instead of `kernel32.dll`.
      
      To solve this I have added another search function that is able to
      search the Windows search paths using `SearchPath` in order to find if
      it is a dll on the system search path.
      
      The new search order is:
      
      ```
      findDll     `orElse`
      findSysDll  `orElse`
      tryGcc      `orElse`
      findArchive `orElse`
      assumeDll
      ```
      
      (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at
      top level)
      
      Test Plan: ./validate added new windows tests T3242
      
      Reviewers: thomie, erikd, hvr, austin, bgamari
      
      Reviewed By: thomie, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1455
      
      GHC Trac Issues: #3242
      acce37f3
  16. 07 Nov, 2015 3 commits
    • kgardas's avatar
      Add OpenBSD specific RTS symbols · 2b7d9c2b
      kgardas authored
      This patch adds OpenBSD specific RTS symbols.  The patch is taken from
      the OpenBSD ports tree, provided by the OpenBSD community.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1445
      2b7d9c2b
    • Tamar Christina's avatar
      Allow the GHCi Linker to resolve related dependencies when loading DLLs · 6e6438e1
      Tamar Christina authored
      Summary:
      GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
      that are not on the standard Windows load path:
      
      1. The directory from which the application loaded.
      2. The current directory.
      3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
      4. The 16-bit system directory. There is no function that obtains the path of this directory,
         but it is searched.
      5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
      6. The directories that are listed in the PATH environment variable.
         Note that this does not include the per-application path specified by the
         AppPaths registry key. The App Paths key is not used when computing the DLL search path.
      
      So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
      If we put both DLLs into a new folder bin and then call GHC with:
      
      `ghc -L$(PWD)/bin -lB`
      
      the loading will fail as the Windows loader will try to load the dependency of `B` and fail
      since it cannot find `A`.
      
      *IMPORTANT* this patch drops XP Support.
      The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
      via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
      not been installed on certain machines. For those machines I display a warning and
      temporarily expand the `PATH` to allow it to load.
      
      This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
      DLL is found are added to the search path. It does so using one of two methods depending upon how
      new of a Windows version we are running on:
      
      - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
         The order of which these directories are searched is nondeterministic.
      - If the APIs are not available it means that we're running on a pretty old unpatched machine.
        But if it's being used in an environment with no internet access it may be the case.
        So if the APIs are not available we temporarily extend the `PATH` with the directories.
        A warning is also displayed to the user informing them that the linking may fail,
        and if it does, install the needed patch. The `PATH` variable has limitations.
      
      Test Plan:
      ./validate
      
      Added two new test T10955 and T10955dyn
      
      Reviewers: erikd, bgamari, thomie, hvr, austin
      
      Reviewed By: erikd, thomie
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1340
      
      GHC Trac Issues: #10955
      6e6438e1
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  17. 26 Oct, 2015 1 commit
  18. 25 Oct, 2015 1 commit
  19. 24 Oct, 2015 1 commit