Re: Problems compiling with llvm-3.5.0-2 on ARM
On 6 November 2014 00:49, Carter Schonwald carter.schonw...@gmail.com wrote: TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4 or older Can we expect 3.5 (3.6) to work with ghc-7.10? (FWIW helloworld seems to work ok with ghc-7.8.3 on x86_64, but not on ARMv7.) Or anyone have any patches? Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [GHC] #9741: Interpreter stack checks are not quite right
| Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug Interesting. I didn't know that. Is that a good idea? Wouldn't it be better to make them independent? Simon | -Original Message- | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf | Of GHC | Sent: 06 November 2014 08:37 | Cc: ghc-tick...@haskell.org | Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right | | #9741: Interpreter stack checks are not quite right | -+ | -- | -+--- |Reporter: simonpj |Owner: simonmar |Type: bug | Status: closed |Priority: highest |Milestone: 7.10.1 | Component: Compiler| Version: 7.8.3 | Resolution: fixed | Keywords: |Operating System: | Architecture: | Unknown/Multiple |Unknown/Multiple | Difficulty: Unknown | Type of failure: | Blocked By: |None/Unknown | Related Tickets: | Test Case: | |Blocking: | | Differential Revisions: | | -+ | -- | -+--- | | Comment (by simonmar): | | Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug`. Incidentally this is probably slowing down | your builds quite a lot, so you might want to turn it off. | | -- | Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9741#comment:5 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | ___ | ghc-tickets mailing list | ghc-tick...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: loadInterfaceForModule
Hi Edward, Thank you for your mail. On 2014-11-05 18:37 (Wednesday), Edward Z. Yang ezy...@mit.edu writes: Hello Gergely, You added a function loadInterfaceForModule which has the exact same type as loadModuleInterface, except when debugging is on it has an extra check to ensure you don't try to load the the current module (this seems like a general invariant that would be good to enforce). As you can imagine after 1 year I only have limited recollection on this, but now I checked out the repository to see the differences for myself and I agree with your assessment, my function seems superfluous. Also loadModuleInterfaces seems to be just a mapM_ of loadModuleInterface instead of the four line implementation. Maybe it is being done like that for performance, but looking into initIfaceTcRn does not seem very expensive. Am I mistaken? Was there any particular reason you created an extra function for this, or can we just use the existing function? Feel free to use the existing one. By the way, these changes were done as part of making it possible for TH to handle annotations, therefore the relevant tests are in tests/annotations (grep for reifyModule). Thanks for taking care of this! Gergely ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Resurrecting ticky code
On Tue, Nov 04, 2014 at 09:52:23AM +, Simon Peyton Jones wrote: We don’t have vectored returns any more, so you can drop that one. Thanks! For magic eight there are some native-wordsize constants defined already. E.g. see how PrelRules.wordSizeInBits is computed. As far as I understood that constant in ticky code was associated with number of bins in the histogram, so I need to find a way to define it both in C and in Haskell (preferably once). Actually there are nine bins, but eight is the index of the last one. Best, Mateusz Thanks to Jan for helping SImon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Mateusz Lenik | Sent: 03 November 2014 17:19 | To: ghc-devs@haskell.org | Subject: Resurrecting ticky code | | Hi *, | | Recently I started working on resurrecting ticky code[1] and got to | the point where I can compile and run bumpHistogram as well as | accompanying code in RTS. | | Work in progress version can be found at [2], but there are few things | remaining to get it working: | | * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and |tickyVectoredReturn need to be added. Unfortunately I'm not familiar | with the |code enough to find the right place to insert them. | | * magic eight needs to be replaced by a constant both Haskell and C | files. |Preprocessor macro seems to be the simplest choice here, however I | don't find |it the cleanest way to do it. | | I would be very grateful if someone could take a look and point me | into the right direction. | | | Best, | Mateusz | | 1: https://ghc.haskell.org/trac/ghc/ticket/8308 | 2: https://github.com/mlen/ghc/compare/ticky | | -- | Mateusz Lenik | GPG: B865 E86A D36C 11A5 C1F8 C1D9 AAD4 CEC9 6B94 92C4 -- Mateusz Lenik GPG: B865 E86A D36C 11A5 C1F8 C1D9 AAD4 CEC9 6B94 92C4 pgpjtex_1fJp0.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ANN: Updating flag description in the User's Guide
Devs, I have some important information for everyone. TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please make absolutely sure that your changes are described in the User's Guide. See Note [Updating flag description in the User's Guide] in DynFlags. TL;DR2 Your help is needed to update the User's Guide. I've spent last two days on updating the flag descriptions in the User's Guide (#9358). Saying that things were a complete mess would be an understatement. We had lots of flags that were not documented in the user's guide, we had documentation for flags that no longer exist, lots of flags were incorrectly labeled as static, etc. It seems that we don't have a habit of updating User's Guide when we change the code responsible for flags. I updated huge chunks of the documentation and things are in a better shape now. But if we forget to update documentation when we make changes then in 2 or 3 years things will most likely be as bad as they were before my clean-up. I added a Note and lots of references to it to remind us about that. If things go well we might even have a Herald rule to remind about updating User's Guide whenever DynFlags and StaticFlags are modified by a commit/revision [1]. However, the task of updating flag descriptions in the User's Guide is not finished. My main focus were the -f*/-fno-* optimisation flags described primarily in sections 4.10 and 4.19.15 (note that HEAD has different section numbers than 7.8.3). I updated what I could but there are still some descriptions missing - I'm not familiar with some of flags that we have. Here's where your help is required. These flags are currently completely missing from the User's Guide: -fbuilding-cabal-package -fflat-cache -fhpc-no-auto -fkill-absence -fkill-one-shot -fsimple-list-literals -fspecialise-aggressively -fuse-rpaths -fspec-constr-recursive -ffloat-lam-args -ffloat-all-lams If you can provide description for any of these flags please edit flags.xml and using.xml. I suspect that -fkill-absence might be related to demand analysis - CCing Nicolas Frisby. Following flags are listed in Flag Reference section (4.19) with a brief one sentence description but they don't have a detailed description in section 4.10 (using.xml): -fcall-arity (CCing Joachim) -funfolding-fun-discount -funfolding-dict-discount -funfolding-keeness-factor -frule-check (see #9776) Following flags have a detailed description but it is confusing: -fdo-eta-reduction -fdo-lambda-eta-expansion Follwoing flags have a description but it is too brief. We should have more details: -fdicts-cheap -fdicts-strict -fdmd-tx-dict-sel (Nicolas, can you update that?) -fmax-inline-memcpy-insns -fmax-inline-memset-insns -fmax-worker-args -fno-opt-coercion -fno-pre-inlining -fsimplifier-phases -fspec-constr-threshold -fspec-constr-count -fstrictness-before These flags were deliberately omitted from the User's Guide because they are deprectaed and will be removed: -fext-core -frewrite-rules For these flags Flag Reference section provides the description of their -fno-* version: -fembed-manifest -fgen-manifest -fghci-history -fghci-sandbox -fpre-inlining -fprint-bind-contents -fprof-count-entries -fshared-implib This seems to go against our convention of describing the flags. Should we revert to desribing their normal version (ie. ones that enable something, not disable)? As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases, which weren;t very useful. And I cleaned up DynFlags by putting some of the long lists of flags into alphabetical order. This change is a bit invasive - I'm sorry if it causes merge conflicts, but I believe that in the long run this is beneficial. As I already said I focused primarily on -f* flags. But we should also make sure that documentation of remaining flags is up to date, especially the -d* ones. I don't have more time to put into this so I'm asking for a collective effort to update the User's Guide, especially that we are moving closer to 7.10 release. Janek [1] https://phabricator.haskell.org/T52 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Daily documentation build?
Hi, a while ago someone said that we have daily builds of the documentation. But... * it is slightly tricky to find it. Starting from https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is also availble” link about daily builds, and then the link from the summary. Ok if one knows where to look, but hard to discover by itself. * it seems that they are not built any more. http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest. Having that would have made it easier for me to review the state of the docs on flags that Jan is writing about. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)
I think this flag is useful for debugging e.g. why something didn't optimize the way you thought. On Nov 6, 2014 1:05 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/ad8457f93807e3b7a9a24867ed69dc93662a29e3/ghc --- commit ad8457f93807e3b7a9a24867ed69dc93662a29e3 Author: Jan Stolarek jan.stola...@p.lodz.pl Date: Wed Nov 5 13:37:25 2014 +0100 Remove -ddump-simpl-phases flag --- ad8457f93807e3b7a9a24867ed69dc93662a29e3 compiler/main/DynFlags.hs| 15 +++ compiler/simplCore/CoreMonad.lhs | 40 ++-- compiler/simplCore/SimplCore.lhs | 9 + docs/users_guide/debugging.xml | 11 --- docs/users_guide/flags.xml | 6 -- 5 files changed, 14 insertions(+), 67 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc ad8457f93807e3b7a9a24867ed69dc93662a29e3 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Daily documentation build?
| * it is slightly tricky to find it. Starting from | https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is | also availble” link about daily builds, and then the link from the | summary. Ok if one knows where to look, but hard to discover by | itself. Where would you expect to find it? Serious question! Here's how you can: GHC home page: https://www.haskell.org/ghc/ Click on Documentation: https://www.haskell.org/haskellwiki/GHC You can find the latest documentation for the current HEAD here But it'd not very prominent. Where else should we add a link? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Joachim Breitner | Sent: 06 November 2014 12:28 | To: ghc-devs@haskell.org | Subject: Daily documentation build? | | Hi, | | a while ago someone said that we have daily builds of the | documentation. | But... | | * it is slightly tricky to find it. Starting from | https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is | also availble” link about daily builds, and then the link from the | summary. Ok if one knows where to look, but hard to discover by | itself. | | * it seems that they are not built any more. | http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest. | | Having that would have made it easier for me to review the state of | the docs on flags that Jan is writing about. | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner |m...@joachim-breitner.de • http://www.joachim-breitner.de/ |Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F |Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: STM and GC write barrier
On 15/09/2014 17:50, Ryan Yates wrote: I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Sorry for the delay, I'm just catching up with this mailing list. Prior to this commit, the garbage collector would treat *all* TVars in the old generation as potentially modified, and traverse them all during every GC. This is expensive when there are a lot of TVars, which meant that TVar-based data structures such as TChan would perform very badly with a large number of elements. The fix is to track writes to TVars in the old generation, which is what that commit did. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Daily documentation build?
Hi, Am Donnerstag, den 06.11.2014, 12:32 + schrieb Simon Peyton Jones: | * it is slightly tricky to find it. Starting from | https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is | also availble” link about daily builds, and then the link from the | summary. Ok if one knows where to look, but hard to discover by | itself. Where would you expect to find it? Serious question! I was expecting that question, but I don’t have a good answer. Probably there where I can actually find it: Sidebar link „Infrastructure“ → link „user documentation“. I guess we are fine. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Fix a couple of inaccurate stack checks (3bebf3c)
Hi Simon, with Am Mittwoch, den 05.11.2014, 18:15 + schrieb g...@git.haskell.org: commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf Author: Simon Marlow marlo...@gmail.com Date: Tue Nov 4 21:31:00 2014 + Fix a couple of inaccurate stack checks I observe a 5% runtime performance regression in nofib’s integer benchmark: http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2base=2%2B68ben=nofib%2Ftime%2Fintegerenv=2revs=50equid=on (The graph looks weird because codespeed doesn’t get the order of commits right.) Expected? Or worth looking into? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANN: Updating flag description in the User's Guide
What about standardizing on an 'experimental' prefix such as -fx-use-rpaths or -fx-kill-oneshot? These flags would not be added to the user guide and their intent clear when actually using them. On Thu, Nov 6, 2014 at 10:28 AM, Simon Marlow marlo...@gmail.com wrote: On 06/11/2014 12:06, Jan Stolarek wrote: Devs, I have some important information for everyone. TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please make absolutely sure that your changes are described in the User's Guide. See Note [Updating flag description in the User's Guide] in DynFlags. TL;DR2 Your help is needed to update the User's Guide. I've spent last two days on updating the flag descriptions in the User's Guide (#9358). Saying that things were a complete mess would be an understatement. We had lots of flags that were not documented in the user's guide, we had documentation for flags that no longer exist, lots of flags were incorrectly labeled as static, etc. It seems that we don't have a habit of updating User's Guide when we change the code responsible for flags. I updated huge chunks of the documentation and things are in a better shape now. But if we forget to update documentation when we make changes then in 2 or 3 years things will most likely be as bad as they were before my clean-up. I added a Note and lots of references to it to remind us about that. If things go well we might even have a Herald rule to remind about updating User's Guide whenever DynFlags and StaticFlags are modified by a commit/revision [1]. Your efforts are much appreciated, thankyou :) These flags are currently completely missing from the User's Guide: -fbuilding-cabal-package -fflat-cache -fhpc-no-auto -fkill-absence -fkill-one-shot -fsimple-list-literals -fspecialise-aggressively -fuse-rpaths -fspec-constr-recursive -ffloat-lam-args -ffloat-all-lams Sometimes we add flags that are for experimentation or development purposes and not intended for user consumption, and these tend not to be added to the User's Guide. I suspect many of the flags you mention fall into this category. I suggest for these we have a specific comment in the source developer use only; undocumented so that we know they don't need to go in the User's Guide. For these flags Flag Reference section provides the description of their -fno-* version: -fembed-manifest -fgen-manifest -fghci-history -fghci-sandbox -fpre-inlining -fprint-bind-contents -fprof-count-entries -fshared-implib This seems to go against our convention of describing the flags. Should we revert to desribing their normal version (ie. ones that enable something, not disable)? Flags that are on by default we often document the no- version deliberately, because this is the form the user is most likely to want. Documenting the positive version sounds strange and is likely to be confusing. I'm surprised you didn't include -fomit-yields here. As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases, isn't -ddump-simpl-phases useful? what's the other way to do that? Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Daily documentation build?
2014-11-06 13:27 GMT+01:00 Joachim Breitner m...@joachim-breitner.de: a while ago someone said that we have daily builds of the documentation. But... I guess that was me, but I cannot do the Windows builds any more, because the Cabal library update broken the build for me. (See my previous mails on the subject, even from a few days back ago.) However, this would be essential to generate a full documentation snapshot. * it seems that they are not built any more. http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest. That is September 18, to be more precise. Having that would have made it easier for me to review the state of the docs on flags that Jan is writing about. Until the Windows build is fixed, I could do documentation builds without the Win32 library if that is okay. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANN: Updating flag description in the User's Guide
Sometimes we add flags that are for experimentation or development purposes and not intended for user consumption, and these tend not to be added to the User's Guide. I suspect many of the flags you mention fall into this category. I suggest for these we have a specific comment in the source developer use only; undocumented so that we know they don't need to go in the User's Guide. I don't like that policy. What if some of the mentioned flags could be useful for my development work but I have no idea how to use these flags because they are not documented? I think we should have these documented as well, possibly with a note saying that this is experimental/unstable. isn't -ddump-simpl-phases useful? what's the other way to do that? I'll reply in a thread started by Johan. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)
Simon Marlow wrote: isn't -ddump-simpl-phases useful? what's the other way to do that? -dverbose-core2core + -ddump-simple-stats Johan Tibell wrote: I think this flag is useful for debugging e.g. why something didn't optimize the way you thought. Well, you can get that information using flags mentioned above. It seemed that -ddump-simpl-phases is not used and can be safely removed. It wasn't documented at all, so the only way to figure out how it works was to look hard at the code. The output itself was rather cryptic - no information about the phase for which the stats are displayed. Again, the only way to make sense of that output was looking at the code to figure out the precise ordering of Core optimisations. With -dverbose-core2core the output makes a lot more sense because it directly follows the output of the phase. Simon PJ and Austin spoke in favour of removing that flag, so I went ahead and did that. But if indeed was used by someone to do their work we could revert that. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANN: Updating flag description in the User's Guide
What about standardizing on an 'experimental' prefix such as -fx-use-rpaths or -fx-kill-oneshot? These flags would not be added to the user guide and their intent clear when actually using them. As already stated in an earlier reply I think we should have documentation for the sake of other developers. I don't like the idea of separate prefix for experimental flags. This could be problematic when the flag becomes stable - we would have to change its name and that would break backwards compatibility. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANN: Updating flag description in the User's Guide
Agreed. For example, the HTTP standard has moved away from X-prefixed headers for similar reasons. On Thu, Nov 6, 2014 at 2:13 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: What about standardizing on an 'experimental' prefix such as -fx-use-rpaths or -fx-kill-oneshot? These flags would not be added to the user guide and their intent clear when actually using them. As already stated in an earlier reply I think we should have documentation for the sake of other developers. I don't like the idea of separate prefix for experimental flags. This could be problematic when the flag becomes stable - we would have to change its name and that would break backwards compatibility. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Resurrecting ticky code
Mateusz, I had a moment to take a look at your patch. Here are some hints: * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and tickyVectoredReturn need to be added. Unfortunately I'm not familiar with the code enough to find the right place to insert them. I think that you should look at StgCmmExpr and try to figure out places that we might be interested in for ticky measurements. For example, I'm looking at cgIdApp and I see we're doing ticky profiling for SlowCall and DirectEntry but we're not doing it for ReturnIt, EnterIt and JumpToIt*. I suggest adding ticky profiling there. I think it's possible to figure out more places where it makes sense to have ticky counters. * magic eight needs to be replaced by a constant both Haskell and C files. Preprocessor macro seems to be the simplest choice here, however I don't find it the cleanest way to do it. I don't know how to define such a constant - I would have to spent some time to try to figure it out. Perhaps you can go to #ghc IRC channel and ask there? Usually there are some people that work on the RTS and might be familiar with how this is done (Edward for example). Oh, and if you're working on a patch please assign yourself as the owner of #8308 so that no one else starts working on this. If you have a patch for review please submit it using Phabricator [1]. Janek [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: STM and GC write barrier
Ok, that explains it. Thanks! On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow marlo...@gmail.com wrote: On 15/09/2014 17:50, Ryan Yates wrote: I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Sorry for the delay, I'm just catching up with this mailing list. Prior to this commit, the garbage collector would treat *all* TVars in the old generation as potentially modified, and traverse them all during every GC. This is expensive when there are a lot of TVars, which meant that TVar-based data structures such as TChan would perform very badly with a large number of elements. The fix is to track writes to TVars in the old generation, which is what that commit did. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Daily documentation build?
I also wonder if it would be nice for Phabricator to upload documentation/artifacts somewhere. Maybe I should implement this, for the Continuous Integration builds on Phab. The main thing is I don't want the build to get all spammy with a million emails, like it did before. But maybe that's workaroundable. On Thu, Nov 6, 2014 at 6:53 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: * it is slightly tricky to find it. Starting from https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is also availble” link about daily builds, and then the link from the summary. Ok if one knows where to look, but hard to discover by itself. Yeah, I had the same problem in the past. That's why I added the link to Infrastructure page (as you have already realized). Seems that the build bots are down. It would be good to have them working again but fixing #9772 would be even better. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
