summaryrefslogtreecommitdiff
path: root/includes/Block.h
Commit message (Collapse)AuthorAgeFilesLines
* RTS tidyup sweep, first phaseSimon Marlow2009-08-021-271/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* don't shrink the stack smaller than the value set by +RTS -k<size>Simon Marlow2009-05-291-0/+9
|
* when a memory leak is detected, report which blocks are unreachableSimon Marlow2008-09-091-1/+2
|
* Experimental "mark-region" strategy for the old generationSimon Marlow2008-06-091-2/+5
| | | | Sometimes better than the default copying, enabled by +RTS -w
* Allow work units smaller than a block to improve load balancingSimon Marlow2008-04-161-0/+1
|
* Release some of the memory allocated to a stack when it shrinks (#2090)simonmar@microsoft.com2008-02-281-9/+18
| | | | | | When a stack is occupying less than 1/4 of the memory it owns, and is larger than a megablock, we release half of it. Shrinking is O(1), it doesn't need to copy the stack.
* round_to_mblocks: should use StgWord not natSimon Marlow2008-02-201-2/+2
|
* Rework the block allocatorSimon Marlow2006-12-141-0/+44
| | | | | | | | The main goal here is to reduce fragmentation, which turns out to be the case of #743. While I was here I found some opportunities to improve performance too. The code is rather more complex, but it also contains a long comment describing the strategy, so please take a look at that for the details.
* replace stgMallocBytesRWX() with our own allocatorSimon Marlow2006-05-301-1/+3
| | | | | | | | | | | | | | | | | | | | See bug #738 Allocating executable memory is getting more difficult these days. In particular, the default SELinux policy on Fedora Core 5 disallows making the heap (i.e. malloc()'d memory) executable, although it does apparently allow mmap()'ing anonymous executable memory by default. Previously, stgMallocBytesRWX() used malloc() underneath, and then tried to make the page holding the memory executable. This was rather hacky and fails with Fedora Core 5. This patch adds a mini-allocator for executable memory, based on the block allocator. We grab page-sized blocks and make them executable, then allocate small objects from the page. There's a simple free function, that will free whole pages back to the system when they are empty.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+202
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.