Hi Johan!
I haven't done much (just been lazy) lately, I've tried to benchmark my
results but I don't get any sensible results at all yet.
Last time Peter said he's working on a more portable way to read dwarf
information that doesn't require Linux. But I'm sure he'll give a more
acurate update than me soon in this mail thread.
As for stack traces, I don't think there's any big tasks left, but I
summarize what I have in mind:
* The haskell interface is done and I've iterated on it a bit, so it's
in a decent shape at least. Some parts still need testing.
* I wish I could implement the `forceCaseContinuation` that I've
described in my thesis. If someone is good with code generation (I
just suck at it, it's probably simple) and is willing to assist me a
bit, please say so. :)
* I tried benchmarking, I gave up after not getting any useful results.
* I'm unfortunately totally incapable to help out with dwarf debug
data generation, only Peter knows that part, particularly I never
grasped his theoretical framework of causality in Haskell.
* Peter and I have finally agreed on a simple and sensible way to
implement `catchWithStack` that have all most good properties you
would like. I just need to implement it and test it. I can
definitely man up and implement this. :)
Here's my master thesis btw [1], it should answer Ömer's question of how
we retrieve a stack from a language you think won't have a stack. :)
Cheers,
Arash
[1]: http://arashrouhani.com/papers/master-thesis.pdf
On 2014-08-13 17:02, Johan Tibell wrote:
Hi,
How's the integration of DWARF support coming along? It's probably one
of the most important improvements to the runtime in quite some time
since unlocks *two* important features, namely
* trustworthy profiling (using e.g. Linux perf events and other
low-overhead, code preserving, sampling profilers), and
* stack traces.
The former is really important to move our core libraries performance
up a notch. Right now -prof is too invasive for it to be useful when
evaluating the hotspots in these libraries (which are already often
heavily tuned).
The latter one is really important for real life Haskell on the
server, where you can sometimes can get some crash that only happens
once a day under very specific conditions. Knowing where the crash
happens is then *very* useful.
-- Johan
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
