| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
| |
|
|
|
|
|
|
|
|
| |
* Some preprocessors don't like the C99/C++ '//' comments after a
directive, so use '/* */' instead. For consistency, a lot of '//' in
the include files were converted, too.
* UnDOSified libraries/base/cbits/runProcess.c.
* My favourite sport: Killed $Id$s.
|
| |
|
|
| |
rearrange #includes
|
| |
|
|
|
| |
Removed the annoying "Id" CVS keywords, they're a real PITA when it
comes to merging...
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Cleanup: all (well, most) messages from the RTS now go through the
functions in RtsUtils: barf(), debugBelch() and errorBelch(). The
latter two were previously called belch() and prog_belch()
respectively. See the comments for the right usage of these message
functions.
One reason for doing this is so that we can avoid spurious uses of
stdout/stderr by Haskell apps on platforms where we shouldn't be using
them (eg. non-console apps on Windows).
|
| |
|
|
|
|
| |
Tweaks to have RTS (C) sources compile with MSVC. Apart from wibbles
related to the handling of 'inline', changed Schedule.h:POP_RUN_QUEUE()
not to use expression-level statement blocks.
|
| |
|
|
| |
to ease replacement of the underlying allocator used by stgMallocBytes() and friends, provide (&use) RtsUtils.c:stgFree()
|
| |
|
|
| |
#include wibbles
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Profiling cleanup.
This commit eliminates some duplication in the various heap profiling
subsystems, and generally centralises much of the machinery. The key
concept is the separation of a heap *census* (which is now done in one
place only instead of three) from the calculation of retainer sets.
Previously the retainer profiling code also did a heap census on the
fly, and lag-drag-void profiling had its own census machinery.
Value-adds:
- you can now restrict a heap profile to certain retainer sets,
but still display by cost centre (or type, or closure or
whatever).
- I've added an option to restrict the maximum retainer set size
(+RTS -R<size>, defaulting to 8).
- I've cleaned up the heap profiling options at the request of
Simon PJ. See the help text for details. The new scheme
is backwards compatible with the old.
- I've removed some odd bits of LDV or retainer profiling-specific
code from various parts of the system.
- the time taken doing heap censuses (and retainer set calculation)
is now accurately reported by the RTS when you say +RTS -Sstderr.
Still to come:
- restricting a profile to a particular biography
(lag/drag/void/use). This requires keeping old heap censuses
around, but the infrastructure is now in place to do this.
|
|
|
Retainer Profiling / Lag-drag-void profiling.
This is mostly work by Sungwoo Park, who spent a summer internship at
MSR Cambridge this year implementing these two types of heap profiling
in GHC.
Relative to Sungwoo's original work, I've made some improvements to
the code:
- it's now possible to apply constraints to retainer and LDV profiles
in the same way as we do for other types of heap profile (eg.
+RTS -hc{foo,bar} -hR -RTS gives you a retainer profiling considering
only closures with cost centres 'foo' and 'bar').
- the heap-profile timer implementation is cleaned up.
- heap profiling no longer has to be run in a two-space heap.
- general cleanup of the code and application of the SDM C coding
style guidelines.
Profiling will be a little slower and require more space than before,
mainly because closures have an extra header word to support either
retainer profiling or LDV profiling (you can't do both at the same
time).
We've used the new profiling tools on GHC itself, with moderate
success. Fixes for some space leaks in GHC to follow...
|
