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, and can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts, and can be resumed by a project maintainer.
Last successful update .
- 25 Nov, 2011 1 commit
-
-
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.
-
- 15 Dec, 2010 1 commit
-
-
Simon Marlow authored
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.
-
- 01 Apr, 2010 1 commit
-
-
Simon Marlow authored
The list of threads blocked on an MVar is now represented as a list of separately allocated objects rather than being linked through the TSOs themselves. This lets us remove a TSO from the list in O(1) time rather than O(n) time, by marking the list object. Removing this linear component fixes some pathalogical performance cases where many threads were blocked on an MVar and became unreachable simultaneously (nofib/smp/threads007), or when sending an asynchronous exception to a TSO in a long list of thread blocked on an MVar. MVar performance has actually improved by a few percent as a result of this change, slightly to my surprise. This is the final cleanup in the sequence, which let me remove the old way of waking up threads (unblockOne(), MSG_WAKEUP) in favour of the new way (tryWakeupThread and MSG_TRY_WAKEUP, which is idempotent). It is now the case that only the Capability that owns a TSO may modify its state (well, almost), and this simplifies various things. More of the RTS is based on message-passing between Capabilities now.
-
- 29 Mar, 2010 2 commits
-
-
Simon Marlow authored
This fixes #3838, and was made possible by the new BLACKHOLE infrastructure. To allow reording of the run queue I had to make it doubly-linked, which entails some extra trickiness with regard to GC write barriers and suchlike.
-
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.
-
- 11 Mar, 2010 1 commit
-
-
Simon Marlow authored
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.
-
- 09 Mar, 2010 1 commit
-
-
Simon Marlow authored
The idea is that this leaves Tasks and OSThread in one-to-one correspondence. The part of a Task that represents a call into Haskell from C is split into a separate struct InCall, pointed to by the Task and the TSO bound to it. A given OSThread/Task thus always uses the same mutex and condition variable, rather than getting a new one for each callback. Conceptually it is simpler, although there are more types and indirections in a few places now. This improves callback performance by removing some of the locks that we had to take when making in-calls. Now we also keep the current Task in a thread-local variable if supported by the OS and gcc (currently only Linux).
-
- 18 Aug, 2009 1 commit
-
-
Simon Marlow authored
There were two bugs, and had it not been for the first one we would not have noticed the second one, so this is quite fortunate. The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a pending exception to raise, but don't end up raising it, there was a missing adjustment to the stack pointer. The second bug was that this case was actually happening at all: it ought to be incredibly rare, because the pending exception thread would have to be killed between us finding it and attempting to raise the exception. This made me suspicious. It turned out that there was a race condition on the tso->flags field; multiple threads were updating this bitmask field non-atomically (one of the bits is the dirty-bit for the generational GC). The fix is to move the dirty bit into its own field of the TSO, making the TSO one word larger (sadly).
-
- 02 Aug, 2009 1 commit
-
-
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.
-
- 22 Jul, 2009 2 commits
- 02 Jun, 2009 1 commit
-
-
Simon Marlow authored
-
- 16 Apr, 2008 1 commit
-
-
simonmarhaskell@gmail.com authored
-
- 26 Jan, 2007 1 commit
-
-
Simon Marlow authored
Similarly to the way we save errno across context switches and suspendThread/resumeThread, we must save and restore the Win32 error code via GetLastError()/SetLastError(). Fixes #896.
-
- 10 Aug, 2006 1 commit
-
-
Simon Marlow authored
-
- 29 Jun, 2006 1 commit
-
-
Simon Marlow authored
So that we can build the RTS with the NCG.
-
- 16 Jun, 2006 1 commit
-
-
Simon Marlow authored
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.
-
- 07 Apr, 2006 1 commit
-
-
Simon Marlow authored
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.
-
- 27 Mar, 2006 1 commit
-
-
Simon Marlow authored
This gives some control over affinity, while we figure out the best way to automatically schedule threads to make best use of the available parallelism. In addition to the primitive, there is also: GHC.Conc.forkOnIO :: Int -> IO () -> IO ThreadId where 'forkOnIO i m' creates a thread on Capability (i `rem` N), where N is the number of available Capabilities set by +RTS -N. Threads forked by forkOnIO do not automatically migrate when there are free Capabilities, like normal threads do. Still, if you're using forkOnIO exclusively, it's a good idea to do +RTS -qm to disable work pushing anyway (work pushing takes too much time when the run queues are large, this is something we need to fix).
-
- 24 Mar, 2006 1 commit
-
-
Simon Marlow authored
There are two new options in the -threaded RTS: -qm Don't automatically migrate threads between CPUs -qw Migrate a thread to the current CPU when it is woken up previously both of these were effectively off, i.e. threads were migrated between CPUs willy-milly, and threads were always migrated to the current CPU when woken up. This is the first step in tweaking the scheduling for more effective work balancing, there will no doubt be more to come.
-
- 23 Jan, 2006 2 commits
-
-
Simon Marlow authored
Along the lines of the clean/dirty arrays and IORefs implemented recently, now threads are marked clean or dirty depending on whether they need to be scanned during a minor GC or not. This should speed up GC when there are lots of threads, especially if most of them are idle.
-
Simon Marlow authored
-
- 21 Oct, 2005 1 commit
-
-
simonmar authored
Big re-hash of the threaded/SMP runtime This is a significant reworking of the threaded and SMP parts of the runtime. There are two overall goals here: - To push down the scheduler lock, reducing contention and allowing more parts of the system to run without locks. In particular, the scheduler does not require a lock any more in the common case. - To improve affinity, so that running Haskell threads stick to the same OS threads as much as possible. At this point we have the basic structure working, but there are some pieces missing. I believe it's reasonably stable - the important parts of the testsuite pass in all the (normal,threaded,SMP) ways. In more detail: - Each capability now has a run queue, instead of one global run queue. The Capability and Task APIs have been completely rewritten; see Capability.h and Task.h for the details. - Each capability has its own pool of worker Tasks. Hence, Haskell threads on a Capability's run queue will run on the same worker Task(s). As long as the OS is doing something reasonable, this should mean they usually stick to the same CPU. Another way to look at this is that we're assuming each Capability is associated with a fixed CPU. - What used to be StgMainThread is now part of the Task structure. Every OS thread in the runtime has an associated Task, and it can ask for its current Task at any time with myTask(). - removed RTS_SUPPORTS_THREADS symbol, use THREADED_RTS instead (it is now defined for SMP too). - The RtsAPI has had to change; we must explicitly pass a Capability around now. The previous interface assumed some global state. SchedAPI has also changed a lot. - The OSThreads API now supports thread-local storage, used to implement myTask(), although it could be done more efficiently using gcc's __thread extension when available. - I've moved some POSIX-specific stuff into the posix subdirectory, moving in the direction of separating out platform-specific implementations. - lots of lock-debugging and assertions in the runtime. In particular, when DEBUG is on, we catch multiple ACQUIRE_LOCK()s, and there is also an ASSERT_LOCK_HELD() call. What's missing so far: - I have almost certainly broken the Win32 build, will fix soon. - any kind of thread migration or load balancing. This is high up the agenda, though. - various performance tweaks to do - throwTo and forkProcess still do not work in SMP mode
-
- 22 Apr, 2005 2 commits
-
-
sof authored
[mingw only] Better handling of I/O request abortions upon throwing an exception to a Haskell thread. As was, a thread blocked on an I/O request was simply unblocked, but its corresponding worker thread wasn't notified that the request had been abandoned. This manifested itself in GHCi upon Ctrl-C being hit at the prompt -- the worker thread blocked waiting for input on stdin prior to Ctrl-C would stick around even though its corresponding Haskell thread had been thrown an Interrupted exception. The upshot was that the worker would consume the next character typed in after Ctrl-C, but then just dropping it. Dealing with this turned out to be even more interesting due to Win32 aborting any console reads when Ctrl-C/Break events are delivered. The story could be improved upon (at the cost of portability) by making the Scheduler able to abort worker thread system calls; as is, requests are cooperatively abandoned. Maybe later. Also included are other minor tidyups to Ctrl-C handling under mingw. Merge to STABLE.
-
simonmar authored
- Now that labels are always prefixed with '&' in .hc code, we have to fix some sloppiness in the RTS .cmm code. Fortunately it's not too painful. - SMP: acquire/release the storage manager lock around atomicModifyMutVar#. This is a hack: atomicModifyMutVar# isn't atomic under SMP otherwise, but the SM lock is a large sledgehammer. I think I'll apply the sledgehammer to the MVar primitives too, for the time being.
-
- 27 Mar, 2005 1 commit
-
-
panne authored
* 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.
-
- 10 Feb, 2005 1 commit
-
-
simonmar authored
GC changes: instead of threading old-generation mutable lists through objects in the heap, keep it in a separate flat array. This has some advantages: - the IND_OLDGEN object is now only 2 words, so the minimum size of a THUNK is now 2 words instead of 3. This saves some amount of allocation (about 2% on average according to my measurements), and is more friendly to the cache by squashing objects together more. - keeping the mutable list separate from the IND object will be necessary for our multiprocessor implementation. - removing the mut_link field makes the layout of some objects more uniform, leading to less complexity and special cases. - I also unified the two mutable lists (mut_once_list and mut_list) into a single mutable list, which lead to more simplifications in the GC.
-
- 28 Jan, 2005 1 commit
-
-
simonmar authored
Rationalise the BUILD,HOST,TARGET defines. Recall that: - build is the platform we're building on - host is the platform we're running on - target is the platform we're generating code for The change is that now we take these definitions as applying from the point of view of the particular source code being built, rather than the point of view of the whole build tree. For example, in RTS and library code, we were previously testing the TARGET platform. But under the new rule, the platform on which this code is going to run is the HOST platform. TARGET only makes sense in the compiler sources. In practical terms, this means that the values of BUILD, HOST & TARGET may vary depending on which part of the build tree we are in. Actual changes: - new file: includes/ghcplatform.h contains platform defines for the RTS and library code. - new file: includes/ghcautoconf.h contains the autoconf settings only (HAVE_BLAH). This is so that we can get hold of these settings independently of the platform defines when necessary (eg. in GHC). - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h. - MachRegs.h, which is included into both the compiler and the RTS, now has to cope with the fact that it might need to test either _TARGET_ or _HOST_ depending on the context. - the compiler's Makefile now generates stage{1,2,3}/ghc_boot_platform.h which contains platform defines for the compiler. These differ depending on the stage, of course: in stage2, the HOST is the TARGET of stage1. This was wrong before. - The compiler doesn't get platform info from Config.hs any more. Previously it did (sometimes), but unless we want to generate a new Config.hs for each stage we can't do this. - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically in CPP'd Haskell source. - ghcplatform.h defines *_TARGET_* for backwards compatibility (ghcplatform.h is included by ghcconfig.h, which is included by config.h, so code which still #includes config.h will get the TARGET settings as before). - The Users's Guide is updated to mention *_HOST_* rather than *_TARGET_*. - coding-style.html in the commentary now contains a section on platform defines. There are further doc updates to come. Thanks to Wolfgang Thaller for pointing me in the right direction.
-
- 18 Nov, 2004 1 commit
-
-
tharris authored
Support for atomic memory transactions and associated regression tests conc041-048
-
- 10 Nov, 2004 1 commit
-
-
wolfgang authored
64-bit fixes. Don't assume that sizeof(int) == sizeof(StgInt). This assumption creeped in in many places since 6.2.
-
- 08 Nov, 2004 1 commit
-
-
simonmar authored
Get rid of SUPPORTS_EMPTY_STRUCTS, and just avoid using empty struct definitions.
-
- 13 Aug, 2004 2 commits
- 01 Mar, 2004 1 commit
-
-
simonmar authored
Threaded RTS improvements: - Make the main_threads list doubly linked. Have threads remove themselves from this list when they complete, rather than searching for completed main threads each time around the scheduler loop. This removes an O(n) loop from the scheduler, but adds some new constraints (basically completed threads must remain on the run queue until dealt with, including threads which have been killed by an async exception). - Add a pointer from the TSO to the StgMainThread struct, for main threads. This avoids a number of places where we had to traverse the list of main threads to find the right one, including one place in the scheduler loop. Adding a field to a TSO is cheap. - taskStart: we should be resetting the startingWorkerThread flag in here. Not sure why we aren't; maybe this got lost at some point. - Use the BlockedOnCCall flags in the non-threaded RTS too. Q: what should happen if a thread does a foreign call which re-enters the RTS, and then sends an async exception to the original thread? Answer: it should deadlock, which it does in the threaded RTS, and this commit makes it do so in the non-threaded RTS too (see testsuite/tests/concurrent/should_run/conc040.hs).
-
- 12 Nov, 2003 1 commit
-
-
sof authored
Tidy up a couple of unportable coding issues: - conditionally use empty structs. - use GNU attributes only if supported. - 'long long' usage - use of 'inline' in declarations and definitions. Upshot of these changes is that MSVC is now capable of compiling the non-.hc portions of the RTS.
-
- 21 Sep, 2003 1 commit
-
-
wolfgang authored
Bound Threads ============= Introduce a way to use foreign libraries that rely on thread local state from multiple threads (mainly affects the threaded RTS). See the file threads.tex in CVS at haskell-report/ffi/threads.tex (not entirely finished yet) for a definition of this extension. A less formal description is also found in the documentation of Control.Concurrent. The changes mostly affect the THREADED_RTS (./configure --enable-threaded-rts), except for saving & restoring errno on a per-TSO basis, which is also necessary for the non-threaded RTS (a bugfix). Detailed list of changes ------------------------ - errno is saved in the TSO object and restored when necessary: ghc/includes/TSO.h, ghc/rts/Interpreter.c, ghc/rts/Schedule.c - rts_mainLazyIO is no longer needed, main is no special case anymore ghc/includes/RtsAPI.h, ghc/rts/RtsAPI.c, ghc/rts/Main.c, ghc/rts/Weak.c - passCapability: a new function that releases the capability and "passes" it to a specific OS thread: ghc/rts/Capability.h ghc/rts/Capability.c - waitThread(), scheduleWaitThread() and schedule() get an optional Capability *initialCapability passed as an argument: ghc/includes/SchedAPI.h, ghc/rts/Schedule.c, ghc/rts/RtsAPI.c - Bound Thread scheduling (that's what this is all about): ghc/rts/Schedule.h, ghc/rts/Schedule.c - new Primop isCurrentThreadBound#: ghc/compiler/prelude/primops.txt.pp, ghc/includes/PrimOps.h, ghc/rts/PrimOps.hc, ghc/rts/Schedule.h, ghc/rts/Schedule.c - a simple function, rtsSupportsBoundThreads, that returns true if THREADED_RTS is defined: ghc/rts/Schedule.h, ghc/rts/Schedule.c - a new implementation of forkProcess (the old implementation stays in place for the non-threaded case). Partially broken; works for the standard fork-and-exec case, but not for much else. A proper forkProcess is really next to impossible to implement: ghc/rts/Schedule.c - Library support for bound threads: Control.Concurrent. rtsSupportsBoundThreads, isCurrentThreadBound, forkOS, runInBoundThread, runInUnboundThread libraries/base/Control/Concurrent.hs, libraries/base/Makefile, libraries/base/include/HsBase.h, libraries/base/cbits/forkOS.c (new file)
-
- 03 Jul, 2003 1 commit
-
-
sof authored
New primop (mingw only), asyncDoProc# :: Addr# -> Addr# -> State# RealWorld-> (# State# RealWorld, Int#, Int# #) which lets a Haskell thread hand off a pointer to external code (1st arg) for asynchronous execution by the RTS worker thread pool. Second arg is data passed in to the asynchronous routine. The routine is _not_ permitted to re-enter the RTS as part of its execution.
-
- 21 Feb, 2003 1 commit
-
-
sof authored
Asynchronous / non-blocking I/O for Win32 platforms. This commit introduces a Concurrent Haskell friendly view of I/O on Win32 platforms. Through the use of a pool of worker Win32 threads, CH threads may issue asynchronous I/O requests without blocking the progress of other CH threads. The issuing CH thread is blocked until the request has been serviced though. GHC.Conc exports the primops that take care of issuing the asynchronous I/O requests, which the IO implementation now takes advantage of. By default, all Handles are non-blocking/asynchronous, but should performance become an issue, having a per-Handle flag for turning off non-blocking could easily be imagined&introduced. [Incidentally, this thread pool-based implementation could easily be extended to also allow Haskell code to delegate the execution of arbitrary pieces of (potentially blocking) external code to another OS thread. Given how relatively gnarly the locking story has turned out to be with the 'threaded' RTS, that may not be such a bad idea.]
-
- 25 Jan, 2003 1 commit
-
-
wolfgang authored
This commit fixes many bugs and limitations in the threaded RTS. There are still some issues remaining, though. The following bugs should have been fixed: - [+] "safe" calls could cause crashes - [+] yieldToReturningWorker/grabReturnCapability - It used to deadlock. - [+] couldn't wake blocked workers - Calls into the RTS could go unanswered for a long time, and that includes ordinary callbacks in some circumstances. - [+] couldn't block on an MVar and expect to be woken up by a signal handler - Depending on the exact situation, the RTS shut down or blocked forever and ignored the signal. - [+] The locking scheme in RtsAPI.c didn't work - [+] run_thread label in wrong place (schedule()) - [+] Deadlock in GHC.Handle - if a signal arrived at the wrong time, an mvar was never filled again - [+] Signals delivered to the "wrong" thread were ignored or handled too late. Issues: *) If GC can move TSO objects (I don't know - can it?), then ghci will occasionally crash when calling foreign functions, because the parameters are stored on the TSO stack. *) There is still a race condition lurking in the code (both threaded and non-threaded RTS are affected): If a signal arrives after the check for pending signals in schedule(), but before the call to select() in awaitEvent(), select() will be called anyway. The signal handler will be executed much later than expected. *) For Win32, GHC doesn't yet support non-blocking IO, so while a thread is waiting for IO, no call-ins can happen. If the RTS is blocked in awaitEvent, it uses a polling loop on Win32, so call-ins should work (although the polling loop looks ugly). *) Deadlock detection is disabled for the threaded rts, because I don't know how to do it properly in the presence of foreign call-ins from foreign threads. This causes the tests conc031, conc033 and conc034 to fail. *) "safe" is currently treated as "threadsafe". Implementing "safe" in a way that blocks other Haskell threads is more difficult than was thought at first. I think it could be done with a few additional lines of code, but personally, I'm strongly in favour of abolishing the distinction. *) Running finalizers at program termination is inefficient - there are two OS threads passing messages back and forth for every finalizer that is run. Also (just as in the non-threaded case) the finalizers are run in parallel to any remaining haskell threads and to any foreign call-ins that might still happen.
-
- 11 Dec, 2002 1 commit
-
-
simonmar authored
Merge the eval-apply-branch on to the HEAD ------------------------------------------ This is a change to GHC's evaluation model in order to ultimately make GHC more portable and to reduce complexity in some areas. At some point we'll update the commentary to describe the new state of the RTS. Pending that, the highlights of this change are: - No more Su. The Su register is gone, update frames are one word smaller. - Slow-entry points and arg checks are gone. Unknown function calls are handled by automatically-generated RTS entry points (AutoApply.hc, generated by the program in utils/genapply). - The stack layout is stricter: there are no "pending arguments" on the stack any more, the stack is always strictly a sequence of stack frames. This means that there's no need for LOOKS_LIKE_GHC_INFO() or LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know how to find the boundary between the text and data segments (BIG WIN!). - A couple of nasty hacks in the mangler caused by the neet to identify closure ptrs vs. info tables have gone away. - Info tables are a bit more complicated. See InfoTables.h for the details. - As a side effect, GHCi can now deal with polymorphic seq. Some bugs in GHCi which affected primitives and unboxed tuples are now fixed. - Binary sizes are reduced by about 7% on x86. Performance is roughly similar, some programs get faster while some get slower. I've seen GHCi perform worse on some examples, but haven't investigated further yet (GHCi performance *should* be about the same or better in theory). - Internally the code generator is rather better organised. I've moved info-table generation from the NCG into the main codeGen where it is shared with the C back-end; info tables are now emitted as arrays of words in both back-ends. The NCG is one step closer to being able to support profiling. This has all been fairly thoroughly tested, but no doubt I've messed up the commit in some way.
-