| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit ugly as we need to assume the structure of the C stack as
left by StgRun. Nevertheless, it allows us to unwind all the way back to
`_start` on my machine.
```
Stack trace:
set_initial_registers (rts/Libdw.c:272.0)
dwfl_thread_getframes
dwfl_getthreads
dwfl_getthread_frames
libdw_get_backtrace (rts/Libdw.c:243.0)
base_GHCziExecutionStack_getStackTrace1_info
(libraries/base/GHC/ExecutionStack.hs:43.1)
base_GHCziExecutionStack_showStackTrace1_info
(libraries/base/GHC/ExecutionStack.hs:47.1)
base_GHCziBase_bindIO1_info (libraries/base/GHC/Base.hs:1085.1)
base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
stg_catch_frame_info (rts/Exception.cmm:370.1)
stg_stop_thread_info (rts/StgStartup.cmm:42.1)
scheduleWaitThread (rts/Schedule.c:465.0)
hs_main (rts/RtsMain.c:65.0)
__libc_start_main (/tmp/buildd/glibc-2.19/csu/libc-start.c:321.0)
_start
```
|
| |
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change here is that the Cmm parser now allows high-level cmm
code with argument-passing and function calls. For example:
foo ( gcptr a, bits32 b )
{
if (b > 0) {
// we can make tail calls passing arguments:
jump stg_ap_0_fast(a);
}
return (x,y);
}
More details on the new cmm syntax are in Note [Syntax of .cmm files]
in CmmParse.y.
The old syntax is still more-or-less supported for those occasional
code fragments that really need to explicitly manipulate the stack.
However there are a couple of differences: it is now obligatory to
give a list of live GlobalRegs on every jump, e.g.
jump %ENTRY_CODE(Sp(0)) [R1];
Again, more details in Note [Syntax of .cmm files].
I have rewritten most of the .cmm files in the RTS into the new
syntax, except for AutoApply.cmm which is generated by the genapply
program: this file could be generated in the new syntax instead and
would probably be better off for it, but I ran out of enthusiasm.
Some other changes in this batch:
- The PrimOp calling convention is gone, primops now use the ordinary
NativeNodeCall convention. This means that primops and "foreign
import prim" code must be written in high-level cmm, but they can
now take more than 10 arguments.
- CmmSink now does constant-folding (should fix #7219)
- .cmm files now go through the cmmPipeline, and as a result we
generate better code in many cases. All the object files generated
for the RTS .cmm files are now smaller. Performance should be
better too, but I haven't measured it yet.
- RET_DYN frames are removed from the RTS, lots of code goes away
- we now have some more canned GC points to cover unboxed-tuples with
2-4 pointers, which will reduce code size a little.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reduces the latency between a context-switch being triggered and
the thread returning to the scheduler, which in turn should reduce the
cost of the GC barrier when there are many cores.
We still retain the old context_switch flag which is checked at the
end of each block of allocation. The idea is that setting HpLim may
fail if the the target thread is modifying HpLim at the same time; the
context_switch flag is a fallback. It also allows us to "context
switch soon" without forcing an immediate switch, which can be costly.
|
| |
|
|
|
|
|
|
|
|
| |
When returning an unboxed tuple with a single non-void component, we
now use the same calling convention as for returning a value of the
same type as that component. This means that the return convention
for IO now doesn't vary depending on the platform, which make some
parts of the RTS simpler, and fixes a problem I was having with making
the FFI work in unregisterised GHCi (the byte-code compiler makes
some assumptions about calling conventions to keep things simple).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements pointer tagging as per our ICFP'07 paper "Faster
laziness using dynamic pointer tagging". It improves performance by
10-15% for most workloads, including GHC itself.
The original patches were by Alexey Rodriguez Yakushev
<mrchebas@gmail.com>, with additions and improvements by me. I've
re-recorded the development as a single patch.
The basic idea is this: we use the low 2 bits of a pointer to a heap
object (3 bits on a 64-bit architecture) to encode some information
about the object pointed to. For a constructor, we encode the "tag"
of the constructor (e.g. True vs. False), for a function closure its
arity. This enables some decisions to be made without dereferencing
the pointer, which speeds up some common operations. In particular it
enables us to avoid costly indirect jumps in many cases.
More information in the commentary:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We changed the convention a while ago so that BaseReg is returned to
the scheduler in R1, because BaseReg may change during the run of a
thread, e.g. during a foreign call. A few places got missed,
mostly for very rare events.
Should fix concprog001, although I'm not able to reliably reproduce
the failure.
|
| |
|
|
|
| |
We recently discovered that they aren't a win any more, and just cost
code size.
|
|
|
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.
|
