April 2013 - ghc-devs

Re: Per-generation lists of weak pointers
by Akio Takano 25 Apr '13

25 Apr '13

Thank you for your comments! On Wed, Apr 24, 2013 at 8:23 PM, Edward Z. Yang <ezyang(a)cs.stanford.edu>wrote: > Great, good to see. > > Some questions: > > - You seem to be stubbing out cfinalizers with stg_WEAK_IS_DEAD_closure > when a weak pointer gets finalized; your locking is predicated on > operations on this field being cas'es. Another design is to lock > the closure itself, via the info table header (using lockClosure). > I think both strategies should be sound, but I suspect lockClosure > is bound to be safer, in case you end up mutating other fields. > You are right, I updated the patches to use lockClosure. I was not aware of the existence of lockClosure when I wrote the previous patches, which is why I used cas(). > - Typo "Kill a weak poitner" > Now the comment is gone. > - There was a comment about LDV which was removed. Why is that comment > irrelevant in the new world order? > In that version of the patches finalizeWeak# didn't modify the infoptr, so the comment didn't apply. It is back in the latest version of the patches, though. > > Edward > > Excerpts from Akio Takano's message of Wed Apr 24 02:12:42 -0700 2013: > > Thank you very much for your help, I just updated the patches on the > ticket. > > > > On Sun, Apr 21, 2013 at 10:50 AM, Edward Z. Yang <ezyang(a)cs.stanford.edu > >wrote: > > > > > In your ticket, you mention this patch introduces a race condition. > One > > > possible fix is to have addCFinalizerToWeak# check if the pointer is > > > already > > > dead, and just run the finalizer immediately if it is. I think this > > > preserves the semantics, but this needs to be checked closely. > > > > > > Edward > > > > > > Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > > > > I removed the invariant by adding a new primop, > addCFinalizerToWeak#. I > > > > opened a ticket for the issue. > > > > > > > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > > > > > > > - Akio > > > > > > > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> > > > wrote: > > > > > > > > > On 11/03/13 03:17, Akio Takano wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I'm working on implementing per-generation lists of weak pointers > to > > > > >> speed up garbage collection in programs that allocate a lot of > weak > > > > >> pointers. I have a patch [1] that validates and gives a 3x speed > up on > > > > >> a benchmark. However I'd like to ask for some advise before > finishing > > > > >> and submitting the patch. > > > > >> > > > > >> [1] https://github.com/takano-**akio/ghc/commit/** > > > > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680< > > > > https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386… > > > > > > > > >> > > > > >> The problem is that since my patch splits the weak pointer list > > > > >> between generations, it no longer maintains the right order of > weak > > > > >> pointers. This could cause finalizers added with > > > > >> addForeignPtrFinalizer to run in the wrong order. > > > > >> > > > > >> I can think of one way to fix it; to make sure that when a WEAK > object > > > > >> gets promoted, it is always added to the front of the new list. > So my > > > > >> questions are: > > > > >> > > > > >> - Would it be a correct fix? > > > > >> - If so, is it an acceptable fix? For example, is it too fragile a > > > > >> reasoning to rely on? > > > > >> > > > > > > > > > > I don't like the way that we rely on the ordering of the weak > pointer > > > list > > > > > right now. I think this invariant arose accidentally when the > support > > > for > > > > > C finalizers was added. It was wrong for some time, see: > > > > > > > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160< > > > http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > > > > > > > and as per my comments in that commit log, I think we should do it > > > > > differently. I don't know how hard that would be though. > > > > > > > > > > Incidentally, I implemented per-generation weak pointers in the > > > local-gc > > > > > branch, but didn't get around to porting it back over into the > > > mainline (I > > > > > still have a ToDo for that). My version probably has the ordering > > > bug, but > > > > > you could always look at the branch to see how my approach > compares to > > > > > yours. > > > > > > > > > > Cheers, > > > > > Simon > > > > > > > > > > > > > >

1 0

Enabling debugging output
by Jan Stolarek 25 Apr '13

25 Apr '13

I have some problems with enabling debugging output. I have broken the compiler in such a way that for some programs I'm getting compiler panic when using some of the flags (-ddump-simpl, -fhpc): Main.h :: GHC.Types.Float -> GHC.Base.String [GblId, Arity=1, Str=DmdType] Main.h =ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130422 for x86_64-unknown-linux): Impossible case alternative I would like to get output from the assertions and warnings placed in the code, for example in this function in simplCore/Simplify.lhs (this is the source of my error message): missingAlt :: SimplEnv -> Id -> [InAlt] -> SimplCont -> SimplM (SimplEnv, OutExpr) missingAlt env case_bndr _ cont = WARN( True, ptext (sLit "missingAlt") <+> ppr case_bndr ) return (env, mkImpossibleExpr (contResultType cont)) I recompiled GHC with the -DDEBUG option, but when I add -debug flag during program compilation I see no output from WARN directive. Are there any additional options I need to enable? Janek P.S. My build.mk has these lines: BuildFlavour = quick ifeq "$(BuildFlavour)" "quick" SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm -Werror -Rghc-timing -DDEBUG GhcStage2HcOpts = -O0 -fasm -Werror -Rghc-timing -DDEBUG GhcLibHcOpts = -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif

1 0

What promotes to (* :: BOX) ?
by Gabor Greif 24 Apr '13

24 Apr '13

Hi devs! I guess I found a gap in the promotion mechanism: > data Prom1 = Symic Symbol gets promoted to to a kind (Prom1 :: BOX) with (Symic "AAA" :: Prom1). So far so good. But how can I define by promotion (Prom2 :: BOX) with (Typic Int :: Prom2) ? I'd like to write > data Prom2 = Typic Type but haven't found such a beast in TypeLits. So my question is basically, which type-level identifier promotes to (* :: BOX) when mentioned in a `data` definition? I am thankful for any hints! Cheers, Gabor

5 7

Re: Proxy, new Typeable, and type-level equality
by Richard Eisenberg 24 Apr '13

24 Apr '13

I have updated the wiki page at http://hackage.haskell.org/trac/ghc/wiki/TypeLevelReasoning with these ideas. If you have further thoughts on all of this, please update that page and send an email out so we know to look at the changes! My timeline for implementing all of this (not hard, but it needs to be done) is around the end of the month. Thanks, Richard On Apr 4, 2013, at 11:11 AM, Edward A Kmett <ekmett(a)gmail.com> wrote: > Note the eq lib and the type-eq/(:~:) GADT-based approach are interchangeable. > > You can upgrade a Leibnizian equality to a type equality by applying the Leibnizian substitution to an a :~: a. > > lens also has a notion of an Equality family at the bottom of the type semilattice for lens-like constructions, which is effectively a naked Leibnizian equality sans newtype wrapper. > > The only reason eq exists is to showcase this approach, but in practice I recommend just using the GADT, modulo mutterings about the name. :) > > That said those lowerings are particularly useful, if subtle -- Oleg wrote the first version of them, which I simplified to the form in that lib and they provide functionality that is classically not derivable for Leibnizian equality. > > Sent from my iPhone > > On Apr 4, 2013, at 3:01 AM, Erik Hesselink <hesselink(a)gmail.com> wrote: > >> On Wed, Apr 3, 2013 at 6:08 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> Comments? Thoughts? >> >> Edward Kmett 'eq' library uses a different definition of equality, but >> can also be an inspiration for useful functions. Particularly, it >> includes: >> >> lower :: (f a :~: f b) -> a :~: b >> >> Another question is where all this is going to live? In a separate >> library? Or in base? And should it really be in a GHC namespace? The >> functionality is not bound to GHC. Perhaps something in data would be >> more appropriate. >> >> Erik >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >

2 2

Re: Per-generation lists of weak pointers
by Akio Takano 24 Apr '13

24 Apr '13

Thank you very much for your help, I just updated the patches on the ticket. On Sun, Apr 21, 2013 at 10:50 AM, Edward Z. Yang <ezyang(a)cs.stanford.edu>wrote: > In your ticket, you mention this patch introduces a race condition. One > possible fix is to have addCFinalizerToWeak# check if the pointer is > already > dead, and just run the finalizer immediately if it is. I think this > preserves the semantics, but this needs to be checked closely. > > Edward > > Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > > I removed the invariant by adding a new primop, addCFinalizerToWeak#. I > > opened a ticket for the issue. > > > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > > > - Akio > > > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> > wrote: > > > > > On 11/03/13 03:17, Akio Takano wrote: > > > > > >> Hi, > > >> > > >> I'm working on implementing per-generation lists of weak pointers to > > >> speed up garbage collection in programs that allocate a lot of weak > > >> pointers. I have a patch [1] that validates and gives a 3x speed up on > > >> a benchmark. However I'd like to ask for some advise before finishing > > >> and submitting the patch. > > >> > > >> [1] https://github.com/takano-**akio/ghc/commit/** > > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680< > https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386… > > > > >> > > >> The problem is that since my patch splits the weak pointer list > > >> between generations, it no longer maintains the right order of weak > > >> pointers. This could cause finalizers added with > > >> addForeignPtrFinalizer to run in the wrong order. > > >> > > >> I can think of one way to fix it; to make sure that when a WEAK object > > >> gets promoted, it is always added to the front of the new list. So my > > >> questions are: > > >> > > >> - Would it be a correct fix? > > >> - If so, is it an acceptable fix? For example, is it too fragile a > > >> reasoning to rely on? > > >> > > > > > > I don't like the way that we rely on the ordering of the weak pointer > list > > > right now. I think this invariant arose accidentally when the support > for > > > C finalizers was added. It was wrong for some time, see: > > > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160< > http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > > > and as per my comments in that commit log, I think we should do it > > > differently. I don't know how hard that would be though. > > > > > > Incidentally, I implemented per-generation weak pointers in the > local-gc > > > branch, but didn't get around to porting it back over into the > mainline (I > > > still have a ToDo for that). My version probably has the ordering > bug, but > > > you could always look at the branch to see how my approach compares to > > > yours. > > > > > > Cheers, > > > Simon > > > > > > >

1 0

installing primitive and vector
by Kazu Yamamoto 23 Apr '13

23 Apr '13

Hello, When building GHC head, primitive and vector are also compiled. But "make install" does not install them. Are there any way to install primitive and vector in addition to other libraries? --Kazu

2 3

Re: ghc-devs Digest, Vol 116, Issue 39
by Kyle Van Berendonck 22 Apr '13

22 Apr '13

Hi, `Implemented getPageFaults for win32` breaks the build. The patch needs some more stuff added. I'll re-submit it soon-ish after I get it to build correctly. Regards. On Mon, Apr 22, 2013 at 8:00 PM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) (Sergei Trofimovich) > 2. Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) (Ian Lynagh) > 3. Re: Fwd: Implemented getPageFaults for win32 (Edward Z. Yang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 21 Apr 2013 21:34:31 +0300 > From: Sergei Trofimovich <slyich(a)gmail.com> > Subject: Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) > To: ghc-devs(a)haskell.org > Cc: ghc-commits(a)haskell.org > Message-ID: <20130421213431.1b0ecc6c@sf> > Content-Type: text/plain; charset="us-ascii" > > > commit 310735e7adce0145c653386c21686b4a1b96aea9 > > Author: Ian Lynagh <ian(a)well-typed.com> > > Date: Sun Apr 21 16:03:40 2013 +0100 > > > > Use ffi_prep_closure_loc rather than ffi_prep_closure > > > > The latter is deprecated. Part of #7718. > > > > >--------------------------------------------------------------- > > > > rts/Adjustor.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/rts/Adjustor.c b/rts/Adjustor.c > > index fbf95df..e4d6e8c 100644 > > --- a/rts/Adjustor.c > > +++ b/rts/Adjustor.c > > @@ -131,7 +131,7 @@ createAdjustor (int cconv, > > barf("createAdjustor: failed to allocate memory"); > > } > > > > - r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/); > > + r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, > code); > > if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r); > > The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be > adjusted as well. > > > return (void*)code; > > -- > > Sergei >

1 0

Fwd: Implemented getPageFaults for win32
by Kyle Van Berendonck 22 Apr '13

22 Apr '13

---------- Forwarded message ---------- From: Kyle Van Berendonck <kvanberendonck(a)gmail.com> Date: Sun, Apr 14, 2013 at 5:56 PM Subject: Implemented getPageFaults for win32 To: ghc-devs(a)haskell.org Author: Kyle Van Berendonck <kvanberendonck(a)gmail.com> 2013-04-14 17:45:39 Committer: Kyle Van Berendonck <kvanberendonck(a)gmail.com> 2013-04-14 17:45:39 Parent: 52efb2c8aefbd448e765e62a34c3e53ab7202a11 (No need to map over all blocks, setting up PIC.) Branch: master Follows: ghc-darcs-git-switchover Precedes: Implemented getPageFaults for win32 ----------------------------- rts/win32/GetTime.c ----------------------------- index bfab43a..50a2c4d 100644 @@ -157,6 +157,13 @@ W_ getPageFaults(void) { /* ToDo (on NT): better, get this via the performance data - that's stored in the registry. */ + that's stored in the registry. + + nb: this includes the number of soft page faults, but it's better than nothing + */ + PROCESS_MEMORY_COUNTERS pmc; + if (GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc))) { + return pmc.PageFaultCount; + } return 0; }

2 1

Re: [commit: ghc] master: Use ffi_prep_closure_loc rather than ffi_prep_closure (310735e)
by Sergei Trofimovich 21 Apr '13

21 Apr '13

> commit 310735e7adce0145c653386c21686b4a1b96aea9 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Sun Apr 21 16:03:40 2013 +0100 > > Use ffi_prep_closure_loc rather than ffi_prep_closure > > The latter is deprecated. Part of #7718. > > >--------------------------------------------------------------- > > rts/Adjustor.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/rts/Adjustor.c b/rts/Adjustor.c > index fbf95df..e4d6e8c 100644 > --- a/rts/Adjustor.c > +++ b/rts/Adjustor.c > @@ -131,7 +131,7 @@ createAdjustor (int cconv, > barf("createAdjustor: failed to allocate memory"); > } > > - r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/); > + r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, code); > if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r); The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be adjusted as well. > return (void*)code; -- Sergei

2 1

Re: Per-generation lists of weak pointers
by Edward Z. Yang 20 Apr '13

20 Apr '13

In your ticket, you mention this patch introduces a race condition. One possible fix is to have addCFinalizerToWeak# check if the pointer is already dead, and just run the finalizer immediately if it is. I think this preserves the semantics, but this needs to be checked closely. Edward Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > I removed the invariant by adding a new primop, addCFinalizerToWeak#. I > opened a ticket for the issue. > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > - Akio > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: > > > On 11/03/13 03:17, Akio Takano wrote: > > > >> Hi, > >> > >> I'm working on implementing per-generation lists of weak pointers to > >> speed up garbage collection in programs that allocate a lot of weak > >> pointers. I have a patch [1] that validates and gives a 3x speed up on > >> a benchmark. However I'd like to ask for some advise before finishing > >> and submitting the patch. > >> > >> [1] https://github.com/takano-**akio/ghc/commit/** > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680<https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386…> > >> > >> The problem is that since my patch splits the weak pointer list > >> between generations, it no longer maintains the right order of weak > >> pointers. This could cause finalizers added with > >> addForeignPtrFinalizer to run in the wrong order. > >> > >> I can think of one way to fix it; to make sure that when a WEAK object > >> gets promoted, it is always added to the front of the new list. So my > >> questions are: > >> > >> - Would it be a correct fix? > >> - If so, is it an acceptable fix? For example, is it too fragile a > >> reasoning to rely on? > >> > > > > I don't like the way that we rely on the ordering of the weak pointer list > > right now. I think this invariant arose accidentally when the support for > > C finalizers was added. It was wrong for some time, see: > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160<http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > and as per my comments in that commit log, I think we should do it > > differently. I don't know how hard that would be though. > > > > Incidentally, I implemented per-generation weak pointers in the local-gc > > branch, but didn't get around to porting it back over into the mainline (I > > still have a ToDo for that). My version probably has the ordering bug, but > > you could always look at the branch to see how my approach compares to > > yours. > > > > Cheers, > > Simon > > > >

1 0