| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
When GHCi is linked dynamically, we still want to be able to load
non-dynamic object files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
I don't think this fixes any bugs as we don't have single-entry thunks
at the moment, but it could cause problems for parallel execution if
we ever did re-introduce update avoidance.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a very rare heap corruption bug, whereby
- a context switch is requested, which sets HpLim to zero
(contextSwitchCapability(), called by the timer signal or
another Capability).
- simultaneously a stack check fails, in a code fragment that has
both a stack and a heap check.
The RTS then assumes that a heap-check failure has occurred and
subtracts HpAlloc from Hp, although in fact it was a stack-check
failure and retreating Hp will overwrite valid heap objects. The bug
is that HpAlloc should only be set when Hp has been incremented by the
heap check. See comments in rts/HeapStackCheck.cmm for more details.
This bug is probably incredibly rare in practice, but I happened to be
working on a test that triggers it reliably:
concurrent/should_run/throwto001, compiled with -O -threaded, args 30
300 +RTS -N2, run repeatedly in a loop.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Allow a temporary assignment to be pushed past an assignment to a
global if the global is not mentioned in the rhs of the assignment we
are inlining.
This fixes up some bad code. We should make sure we're doing
something equivalent in the new backend in due course.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Here's the obscure problem:
-- However, we also want to allow an assignment to be generated
-- in the case when the types are compatible, because this allows
-- some slightly-dodgy but occasionally-useful casts to be used,
-- such as in RtClosureInspect where we cast an HValue to a MutVar#
-- so we can print out the contents of the MutVar#. If we generate
-- code that enters the HValue, then we'll get a runtime panic, because
-- the HValue really is a MutVar#. The types are compatible though,
-- so we can just generate an assignment.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The card table is an array of bytes, placed directly following the
actual array data. This means that array reading is unaffected, but
array writing needs to read the array size from the header in order to
find the card table.
We use a bytemap rather than a bitmap, because updating the card table
must be multi-thread safe. Each byte refers to 128 entries of the
array, but this is tunable by changing the constant
MUT_ARR_PTRS_CARD_BITS in includes/Constants.h.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The native back ends had difficulties with loops;
in particular the code for branch-chain elimination
could run in infinite loops or drop basic blocks.
The old codeGen didn't expose these problems.
Also, my fix for T3286 in the new codegen was getting
applied to too many (some wrong) cases; a better pattern
match fixed that.
|
| |
|
|
|
|
|
| |
When we used derived pointers into the middle of an object,
we need to keep the pointer to the start of the object live.
We use a "fat machine instruction" with the primitive MO_Touch
to propagate this information through the back end.
|
| |
|
|
|
|
| |
Apparently, the arguments should be sorted by pointerhood.
While we're at it, I rewrote the code that assigns registers
and stack space to function call and return parameters.
|
| |
|
|
|
|
|
|
|
| |
If the scrutinee is bottom, the generated Cmm code could have a
type error when the case arm expected an unboxed floating-point
value (even though the arm should never be reached).
Now, we detect this case and avoid producing the type-incorrect
assignment.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of the CmmLabel ctor is now
CmmLabel :: PackageId -> FastString -> CmmLabelInfo -> CLabel
- When you construct a CmmLabel you have to explicitly say what
package it is in. Many of these will just use rtsPackageId, but
I've left it this way to remind people not to pretend labels are
in the RTS package when they're not.
- When parsing a Cmm file, labels that are not defined in the
current file are assumed to be in the RTS package.
Labels imported like
import label
are assumed to be in a generic "foreign" package, which is different
from the current one.
Labels imported like
import "package-name" label
are marked as coming from the named package.
This last one is needed for the integer-gmp library as we want to
refer to labels that are not in the same compilation unit, but
are in the same non-rts package.
This should help remove the nasty #ifdef __PIC__ stuff from
integer-gmp/cbits/gmp-wrappers.cmm
|
| | |
|
| |
|
|
| |
This one complains sometimes, but there's no good way to improve it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
It still lives in darcs, if anyone wants to revive it sometime.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It adds a third case to StgOp which already hold StgPrimOp and StgFCallOp.
The code generation for the new StgPrimCallOp case is almost exactly the
same as for out-of-line primops. They now share the tailCallPrim function.
In the Core -> STG translation we map foreign calls using the "prim"
calling convention to the StgPrimCallOp case. This is because in Core we
represent prim calls using the ForeignCall stuff. At the STG level however
the prim calls are really much more like primops than foreign calls.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of these things is not like the others:
stdPattern :: [LRep] -> Maybe StgHalfWord
stdPattern reps
= case reps of
[] -> Just ARG_NONE -- just void args, probably
[N] -> Just ARG_N
[P] -> Just ARG_N
[F] -> Just ARG_F
[D] -> Just ARG_D
[L] -> Just ARG_L
Today's debugging session was brought to you by the letter P.
|
| |
|
|
|
|
| |
- Previously, the node was taken as a parameter, then ignored,
for static closures. Goofy. Now, the vestigial node parameters
are gone.
|
| | |
|
| |
|
|
| |
node argument is managed
|
| | |
|
| |
|
|
| |
making calls
|
| | |
|
| | |
|
| |
|
|
|
| |
- yet another wrong calling convention; this one was a special case for returning one
value.
|
| |
|
|
|
| |
- The function argument was stripped from the argument list but not from the type.
Now they're both stripped.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since we introduced pointer tagging, we no longer always enter a
closure to evaluate it. However, the biographical profiler relies on
closures being entered in order to mark them as "used", so we were
getting spurious amounts of data attributed to VOID. It turns out
there are various places that need to be fixed, and I think at least
one of them was also wrong before pointer tagging (CgCon.cgReturnDataCon).
|
