| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Implement the mblock map for 64-bit architectures.
Fairly primitive data structure, but one 4GB-block, described by a
12-bit block map, is cached for speed.
Note that I've nuked the ia64-specific version (I think ia64 wants to
use the general 64-bit solution, too).
|
| |
|
|
|
| |
Removed the annoying "Id" CVS keywords, they're a real PITA when it
comes to merging...
|
| |
|
|
| |
Merge backend-hacking-branch onto HEAD. Yay!
|
| |
|
|
| |
Generalise the x86-64 hack to all 64-bit arches.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initial x86-64 (aka amd64) support.
Unregisterised it works perfectly. Registerised, I think it's almost
there, except that I seem to be running into the known codegen bug in
GCC with register variables (bug #7871 in the gcc bugzilla), which
means registerised support is basically hosed until the GCC folks
can get their act together.
We get 8 more registers on amd64, but only 2 more callee-saves
registers. The calling convention seems to pass args in registers by
default, using the previously-callee-saves %rsi and %rdi as two of the
new arg registers.
I think GHCi should work, since we already have 64-bit ELF support
thanks to Mat Chapman's work on the IA64 port. I haven't tried GHCi,
though.
The native code generator should be a breeze, because it's so similar
to plain x86.
|
| |
|
|
| |
TEXT_BEFORE_HEAP is not used any more.
|
| |
|
|
| |
Update HEAP_ALLOCED implementation for IA64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bite the bullet and generalise the central memory allocation scheme.
Previously we tried to allocate memory starting from a fixed address,
which was set for each architecture (0x5000000 was a common one), and
to decide whether a particular address was in the heap or not we would
do a simple comparison against this address.
This doesn't work too well, because:
- if we dynamically-load some objects above the boundary, the
heap-allocated test becomes invalid
- on windows we have less control, and the heap might be
split into multiple sections
- it turns out that on some Linux kernels we don't get memory where
we asked for it. This might be a bug in those kernels, but it
exposes the fragility of our allocation scheme.
The solution is to bite the bullet and maintain a table mapping
addresses to a value indicating whether that address is in the heap or
not. Since we normally allocate heap in chunks of 1Mb, the table is
quite small: 4k on a 32-bit machine, using one byte for each 1Mb
block. Testing an address for heap residency now involves a memory
access, but the table is normally cache-resident. I didn't manage to
measure any slowdown after making the change.
On a 64-bit machine, we'll need to use a 2-level table; I haven't
implemented that yet.
Now we can generalise the procedure used to grab memory from the OS.
In the general case, we allocate one megablock more than we need to,
and trim off the slop around the allocation to leave an aligned chunk.
The next time around, however, we try to allocate memory right after
the last chunk allocated, on the grounds that it is aligned and
probably free: if this doesn't work, we have to back off to the
general mechanism (it seems to work most of the time).
This cleans up the Windows story too: is_heap_alloced() has gone, and
we should be able to handle more than 256M of memory (or whatever the
arbitrary limit was before).
MERGE TO STABLE (after lots of testing)
|
| |
|
|
|
|
|
| |
IA64 only changes:
* Place HEAP_BASE in an appropriate place
* On IA64, use GCC "section" attribute to coax compiler into putting info
tables in .text
|
| |
|
|
| |
widen the scope of is_heap_alloced() proto; for all mingw builds
|
| |
|
|
| |
multi-slurp protect
|
| |
|
|
| |
MacOS X 10.1 identifies as "darwin"
|
| |
|
|
| |
The heap shall start at HEAP_BASE == 0x180000000L on alpha-osf3.
|
| |
|
|
| |
Test for mingw32_TARGET_OS and cygwin32_TARGET_OS instead of WIN32.
|
| |
|
|
| |
add MacOSX HEAP_BASE
|
| |
|
|
| |
merge recent changes from before-ghci-branch onto the HEAD
|
| |
|
|
| |
Misc tweaks to Win32 DLL setup
|
| |
|
|
|
|
|
|
|
| |
Added is_heap_alloced() to the API - returns true if an address is
within the range of addresses that we've been given back from the
OS.
Only needed for Win32 DLLs, so it's only defined when compiling up
a Win32 RTS DLL.
|
| |
|
|
| |
Copyright police.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a generational garbage collector.
The collector is reliable but fairly untuned as yet. It works with an
arbitrary number of generations: use +RTS -G<gens> to change the
number of generations used (default 2).
Stats: +RTS -Sstderr is quite useful, but to really see what's going
on compile the RTS with -DDEBUG and use +RTS -D32.
ARR_PTRS removed - it wasn't used anywhere.
Sanity checking improved:
- free blocks are now spammed when sanity checking is turned on
- a check for leaking blocks is performed after each GC.
|
|
|
Move 4.01 onto the main trunk.
|
