summaryrefslogtreecommitdiff
path: root/rts/Trace.h
Commit message (Collapse)AuthorAgeFilesLines
* Revert "rts: add Emacs 'Local Variables' to every .c file"Simon Marlow2014-09-291-8/+0
| | | | This reverts commit 39b5c1cbd8950755de400933cecca7b8deb4ffcd.
* rts: add Emacs 'Local Variables' to every .c fileAustin Seipp2014-07-281-0/+8
| | | | | | | | This will hopefully help ensure some basic consistency in the forward by overriding buffer variables. In particular, it sets the wrap length, the offset to 4, and turns off tabs. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Add a new traceMarker# primop for use in profiling outputDuncan Coutts2012-10-151-0/+10
| | | | | | | | | In time-based profiling visualisations (e.g. heap profiles and ThreadScope) it would be useful to be able to mark particular points in the execution and have those points in time marked in the visualisation. The traceMarker# primop currently emits an event into the eventlog. In principle it could be extended to do something in the heap profiling too.
* Deprecate lnat, and use StgWord insteadSimon Marlow2012-09-071-22/+22
| | | | | | | | | | | | lnat was originally "long unsigned int" but we were using it when we wanted a 64-bit type on a 64-bit machine. This broke on Windows x64, where long == int == 32 bits. Using types of unspecified size is bad, but what we really wanted was a type with N bits on an N-bit machine. StgWord is exactly that. lnat was mentioned in some APIs that clients might be using (e.g. StackOverflowHook()), so we leave it defined but with a comment to say that it's deprecated.
* Fix build on OS XIan Lynagh2012-07-151-2/+2
|
* Fix dtraceTaskCreateIan Lynagh2012-07-151-4/+6
| | | | The tid argument was missing
* Fix a CPP typoIan Lynagh2012-07-141-1/+1
|
* Have a go at fixing the heap info DTrace build failue on OSXDuncan Coutts2012-07-101-19/+0
| | | | | | | | This patch will need to be tested by someone on OSX. Fixed a couple wrong names: CapsetID vs EventCapsetID gc__sync vs gc__global__sync
* Define the task-tracking eventsDuncan Coutts2012-07-101-0/+62
| | | | | | | | | | | | | Based on initial patches by Mikolaj Konarski <mikolaj@well-typed.com> These new eventlog events are to let profiling tools keep track of all the OS threads that belong to an RTS capability at any moment in time. In the RTS, OS threads correspond to the Task abstraction, so that is what we track. There are events for tasks being created, migrated between capabilities and deleted. In particular the task creation event also records the kernel thread id which lets us match up the OS thread with data collected by others tools (in the initial use case with Linux's perf tool, but in principle also with DTrace).
* Fix RTS build on OS XManuel M T Chakravarty2012-04-101-2/+20
| | | | | | * The following commits made validate fail on OS X (Lion): 65aaa9b2715c5245838123f3a0fa5d92e0a66bce and c294d95dc04950ab4c5380bf6ce8651f621f8591 * I just commented out all offending code until it validated again. The original authors need to clean this up.
* Add the GC_GLOBAL_SYNC event marking that all caps are stopped for GCMikolaj2012-04-041-0/+9
| | | | | | | | | Quoting design rationale by dcoutts: The event indicates that we're doing a stop-the-world GC and all other HECs should be between their GC_START and GC_END events at that moment. We don't want to use GC_STATS_GHC for that, because GC_STATS_GHC is for extra GHC-specific info, not something we have to rely on to be able to match the GC pauses across HECs to a particular global GC.
* Fix the timestamps in GC_START and GC_END events on the GC-initiating capMikolaj2012-04-041-0/+25
| | | | | | | | | | | There was a discrepancy between GC times reported in +RTS -s and the timestamps of GC_START and GC_END events on the cap, on which +RTS -s stats for the given GC are based. This is fixed by posting the events with exactly the same timestamp as generated for the stat calculation. The calls posting the events are moved too, so that the events are emitted close to the time instant they claim to be emitted at. The GC_STATS_GHC was moved, too, ensuring it's emitted before the moved GC_END on all caps, which simplifies tools code.
* Add new eventlog events for various heap and GC statisticsDuncan Coutts2012-04-041-2/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They cover much the same info as is available via the GHC.Stats module or via the '+RTS -s' textual output, but via the eventlog and with a better sampling frequency. We have three new generic heap info events and two very GHC-specific ones. (The hope is the general ones are usable by other implementations that use the same eventlog system, or indeed not so sensitive to changes in GHC itself.) The general ones are: * total heap mem allocated since prog start, on a per-HEC basis * current size of the heap (MBlocks reserved from OS for the heap) * current size of live data in the heap Currently these are all emitted by GHC at GC time (live data only at major GC). The GHC specific ones are: * an event giving various static heap paramaters: * number of generations (usually 2) * max size if any * nursary size * MBlock and block sizes * a event emitted on each GC containing: * GC generation (usually just 0,1) * total bytes copied * bytes lost to heap slop and fragmentation * the number of threads in the parallel GC (1 for serial) * the maximum number of bytes copied by any par GC thread * the total number of bytes copied by all par GC threads (these last three can be used to calculate an estimate of the work balance in parallel GCs)
* Add eventlog/trace stuff for capabilities: create/delete/enable/disableDuncan Coutts2012-04-041-19/+50
| | | | | | | | | | | | | | | | | | | | | | | Now that we can adjust the number of capabilities on the fly, we need this reflected in the eventlog. Previously the eventlog had a single startup event that declared a static number of capabilities. Obviously that's no good anymore. For compatability we're keeping the EVENT_STARTUP but adding new EVENT_CAP_CREATE/DELETE. The EVENT_CAP_DELETE is actually just the old EVENT_SHUTDOWN but renamed and extended (using the existing mechanism to extend eventlog events in a compatible way). So we now emit both EVENT_STARTUP and EVENT_CAP_CREATE. One day we will drop EVENT_STARTUP. Since reducing the number of capabilities at runtime does not really delete them, it just disables them, then we also have new events for disable/enable. The old EVENT_SHUTDOWN was in the scheduler class of events. The new EVENT_CAP_* events are in the unconditional class, along with the EVENT_CAPSET_* ones. Knowing when capabilities are created and deleted is crucial to making sense of eventlogs, you always want those events. In any case, they're extremely low volume.
* Allow the number of capabilities to be increased at runtime (#3729)Simon Marlow2011-12-061-0/+1
| | | | | At present the number of capabilities can only be *increased*, not decreased. The latter presents a few more challenges!
* Add eventlog event for thread labelsDuncan Coutts2011-11-041-0/+23
| | | | | | The existing GHC.Conc.labelThread will now also emit the the thread label into the eventlog. Profiling tools like ThreadScope could then use the thread labels rather than thread numbers.
* Add an RTS eventlog tracing class for user messagesDuncan Coutts2011-10-271-0/+1
| | | | Enables people to turn them on/off. Defaults to on.
* Add new eventlog EVENT_WALL_CLOCK_TIME for time matchingDuncan Coutts2011-10-261-0/+10
| | | | | | | | | | | | | | Eventlog timestamps are elapsed times (in nanoseconds) relative to the process start. To be able to merge eventlogs from multiple processes we need to be able to align their timelines. If they share a clock domain (or a user judges that their clocks are sufficiently closely synchronised) then it is sufficient to know how the eventlog timestamps match up with the clock. The EVENT_WALL_CLOCK_TIME contains the clock time with (up to) nanosecond precision. It is otherwise an ordinary event and so contains the usual timestamp for the same moment in time. It therefore enables us to match up all the eventlog timestamps with clock time.
* Rename traceCapsetModify for consistency and clarityDuncan Coutts2011-10-261-8/+8
|
* Fix build on OSX, thanks to David PeixottoBen Lippmeier2011-07-221-1/+1
|
* Add new fully-accurate per-spark trace/eventlog eventsDuncan Coutts2011-07-181-38/+90
| | | | | | | | | | | | | | Replaces the existing EVENT_RUN/STEAL_SPARK events with 7 new events covering all stages of the spark lifcycle: create, dud, overflow, run, steal, fizzle, gc The sampled spark events are still available. There are now two event classes for sparks, the sampled and the fully accurate. They can be enabled/disabled independently. By default +RTS -l includes the sampled but not full detail spark events. Use +RTS -lf-p to enable the detailed 'f' and disable the sampled 'p' spark. Includes work by Mikolaj <mikolaj.konarski@gmail.com>
* Move GC tracing into a separate trace classDuncan Coutts2011-07-181-30/+31
| | | | | | | Previously GC was included in the scheduler trace class. It can be enabled specifically with +RTS -vg or -lg, though note that both -v and -l on their own now default to a sensible set of trace classes, currently: scheduler, gc and sparks.
* include spark counters in the sparks trace classMikolaj2011-07-181-1/+1
|
* add a new trace class for spark eventsDuncan Coutts2011-07-181-3/+10
|
* Add spark counter tracingDuncan Coutts2011-07-181-16/+42
| | | | | | | A new eventlog event containing 7 spark counters/statistics: sparks created, dud, overflowed, converted, GC'd, fizzled and remaining. These are maintained and logged separately for each capability. We log them at startup, on each GC (minor and major) and on shutdown.
* Fix build on OS X: Correct silly errors in Trace.hIan Lynagh2011-06-271-3/+3
|
* Fix gcc 4.6 warnings; fixes #5176Ian Lynagh2011-06-251-3/+4
| | | | | | | | | | | Based on a patch from David Terei. Some parts are a little ugly (e.g. defining things that only ASSERTs use only when DEBUG is defined), so we might want to tweak things a little. I've also turned off -Werror for didn't-inline warnings, as we now get a few such warnings.
* Fix a typo in a commentIan Lynagh2011-06-251-1/+1
|
* Emit various bits of OS process info into the eventlogDuncan Coutts2011-05-261-0/+10
| | | | | The process ID, parent process ID, rts name and version The program arguments and environment.
* Add capability sets to the tracing/events systemDuncan Coutts2011-05-261-0/+60
| | | | | | | We trace the creation and shutdown of capabilities. All the capabilities in the process are assigned to one capabilitiy set of OS-process type. This is a second version of the patch. Includes work by Spencer Janssen.
* Make the tracing of the startup event more regularDuncan Coutts2011-05-261-6/+10
| | | | Rather than doing it differently for the eventlog and Dtrace cases.
* Revert "Add capability sets to the event system. Contains code from Duncan ↵Duncan Coutts2011-05-231-69/+0
| | | | | | | | Coutts." This reverts commit 58532eb46041aec8d4cbb48b054cb5b001edb43c. Turns out it didn't work on Windows and it'll need some non-trivial changes to make it work on Windows. We'll get it in later once that's sorted out.
* Add capability sets to the event system. Contains code from Duncan Coutts.Spencer Janssen2011-05-181-0/+69
|
* Annotate thread stop events with the owner of the black holeSimon Marlow2011-01-271-8/+15
| | | | | | | | | So we can now get these in ThreadScope: 19487000: cap 1: stopping thread 6 (blocked on black hole owned by thread 4) Note: needs an update to ghc-events. Older ThreadScopes will just ignore the new information.
* Implement stack chunks and separate TSO/STACK objectsSimon Marlow2010-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes two changes to the way stacks are managed: 1. The stack is now stored in a separate object from the TSO. This means that it is easier to replace the stack object for a thread when the stack overflows or underflows; we don't have to leave behind the old TSO as an indirection any more. Consequently, we can remove ThreadRelocated and deRefTSO(), which were a pain. This is obviously the right thing, but the last time I tried to do it it made performance worse. This time I seem to have cracked it. 2. Stacks are now represented as a chain of chunks, rather than a single monolithic object. The big advantage here is that individual chunks are marked clean or dirty according to whether they contain pointers to the young generation, and the GC can avoid traversing clean stack chunks during a young-generation collection. This means that programs with deep stacks will see a big saving in GC overhead when using the default GC settings. A secondary advantage is that there is much less copying involved as the stack grows. Programs that quickly grow a deep stack will see big improvements. In some ways the implementation is simpler, as nothing special needs to be done to reclaim stack as the stack shrinks (the GC just recovers the dead stack chunks). On the other hand, we have to manage stack underflow between chunks, so there's a new stack frame (UNDERFLOW_FRAME), and we now have separate TSO and STACK objects. The total amount of code is probably about the same as before. There are new RTS flags: -ki<size> Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m -kc<size> Sets the stack chunk size (default 32k) -kb<size> Sets the stack chunk buffer size (default 1k) -ki was previously called just -k, and the old name is still accepted for backwards compatibility. These new options are documented.
* Only reset the event log if logging is turned on (addendum to #4512)Simon Marlow2010-12-101-0/+1
|
* Fix the symbol visibility pragmasSimon Marlow2010-06-171-2/+2
|
* Use message-passing to implement throwTo in the RTSSimon Marlow2010-03-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces some complicated locking schemes with message-passing in the implementation of throwTo. The benefits are - previously it was impossible to guarantee that a throwTo from a thread running on one CPU to a thread running on another CPU would be noticed, and we had to rely on the GC to pick up these forgotten exceptions. This no longer happens. - the locking regime is simpler (though the code is about the same size) - threads can be unblocked from a blocked_exceptions queue without having to traverse the whole queue now. It's a rare case, but replaces an O(n) operation with an O(1). - generally we move in the direction of sharing less between Capabilities (aka HECs), which will become important with other changes we have planned. Also in this patch I replaced several STM-specific closure types with a generic MUT_PRIM closure type, which allowed a lot of code in the GC and other places to go away, hence the line-count reduction. The message-passing changes resulted in about a net zero line-count difference.
* Expose all EventLog events as DTrace probesManuel M T Chakravarty2009-12-121-1/+236
| | | | | | | | | | | | | | - 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
* Add events to show when GC threads are idle/workingSimon Marlow2009-10-151-0/+12
|
* Add a way to generate tracing events programmaticallySimon Marlow2009-09-251-0/+5
| | | | | | | | | | | | | | added: primop TraceEventOp "traceEvent#" GenPrimOp Addr# -> State# s -> State# s { Emits an event via the RTS tracing framework. The contents of the event is the zero-terminated byte string passed as the first argument. The event will be emitted either to the .eventlog file, or to stderr, depending on the runtime RTS flags. } and added the required RTS functionality to support it. Also a bit of refactoring in the RTS tracing code.
* Optimise the code generated at trace pointsSimon Marlow2009-09-121-118/+67
|
* Omit visibility pragmas on Windows (fixes warnings/validate failures)Simon Marlow2009-09-091-2/+2
|
* Unify event logging and debug tracing.Simon Marlow2009-08-291-38/+134
| | | | | | | | | | | | | | | | | | | - 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.
* Declare RTS-private prototypes with __attribute__((visibility("hidden")))Simon Marlow2009-08-051-0/+4
| | | | | | | | | | This has no effect with static libraries, but when the RTS is in a shared library it does two things: - it prevents the function from being exposed by the shared library - internal calls to the function can use the faster non-PLT calls, because the function cannot be overriden at link time.
* Add fast event loggingSimon Marlow2009-03-171-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Add +RTS -vg flag for requesting some GC trace messages, outside DEBUGSimon Marlow2008-04-161-7/+4
| | | | | | | DEBUG imposes a significant performance hit in the GC, yet we often want some of the debugging output, so -vg gives us the cheap trace messages without the sanity checking of DEBUG, just like -vs for the scheduler.
* kill the PAR/GRAN debug flagssimonmar@microsoft.com2007-11-221-30/+1
|
* Using RTS debug tracing support inside Hpc.candy@galois.com2007-02-131-0/+2
|
* Asynchronous exception support for SMPSimon Marlow2006-06-161-2/+2
| | | | | | | | | | | | | | | | | This patch makes throwTo work with -threaded, and also refactors large parts of the concurrency support in the RTS to clean things up. We have some new files: RaiseAsync.{c,h} asynchronous exception support Threads.{c,h} general threading-related utils Some of the contents of these new files used to be in Schedule.c, which is smaller and cleaner as a result of the split. Asynchronous exception support in the presence of multiple running Haskell threads is rather tricky. In fact, to my annoyance there are still one or two bugs to track down, but the majority of the tests run now.
View Lorry Controller Status