June 2004 - Glasgow-haskell-users

RE: Understanding strictness of ghc output
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 15:11, Duncan Coutts wrote: > On Tue, 2004-06-22 at 14:17, Tomasz Zielonka wrote: >> On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: >>> >>> Same again. Try >>> addHeight h E = h `seq` h >>> >>> which, although it looks bizarre, actually forces the evaluation of >>> h, whilst simply returning it does not. >> >> That contradicts my intution for seq. I would read it as "h is forced >> before h is forced", and I would think that (h `seq` h) is equivalent >> to h. > > I think a better intuition is that "h is forced before h is > *returned*". You can return a value without that value being forced > to head normal form. In fact this is the ordinary case. Values are > only 'forced' when you pattern match on them (or if you use seq), and > even then only when the result of the pattern match is used. Nope. You can't return something without evaluating it to head normal form in Haskell. Every value that is "returned" is a value, never a thunk. If you want to return something unevaluated, you have to wrap it in a constructor. h `seq` h is the same as h. addHeight is strict in h, no seq is necessary. If there's a Haskell implementation that compiles addHeight in such a way that addHeight _|_ e /= _|_, then I'd say it was wrong (but we don't have an official denotational semantics for Haskell, only an informal agreement ;-). Cheers, Simon

3 2

Understanding strictness of ghc output
by Adrian Hey 22 Jun '04

22 Jun '04

Hello, I'm trying to figure out how you tell if ghc has correctly infered strictness or whether or not a little more prompting from me is needed. I tried compiling with -ddump-simpl, and I guess from looking at this the DmdType bit is what I want (maybe). So if I have "DmdType LS" for a function of arity 2, does this mean the function is lazy in the first argument and strict in the second? I would be pretty confident that this was the correct interpretation, but this is the Haskell code (from AVL library).. height :: AVL e -> Int height = addHeight 0 where addHeight h E = h addHeight h (N l _ _) = addHeight h+2 l addHeight h (Z l _ _) = addHeight h+1 l addHeight h (P _ _ r) = addHeight h+2 r It seems pretty obvious to me that addHeight is strict in its first argument if + is strict for Ints (as I guess it is). But this gives "DmdType LS". Even if I rewrite it.. height :: AVL e -> Int height = addHeight 0 where addHeight h E = h addHeight h (N l _ _) = let h' = h+2 in h' `seq` addHeight h' l addHeight h (Z l _ _) = let h' = h+1 in h' `seq` addHeight h' l addHeight h (P _ _ r) = let h' = h+2 in h' `seq` addHeight h' r .. it still gives "DmdType LS". So does this.. height :: AVL e -> Int height = addHeight 0 where addHeight h E = h addHeight h (N l _ _) = h `seq` addHeight (h+2) l addHeight h (Z l _ _) = h `seq` addHeight (h+1) l addHeight h (P _ _ r) = h `seq` addHeight (h+2) r So am I interpreting core correctly? Thanks -- Adrian Hey

6 5

RE: Understanding strictness of ghc output
by Simon Peyton-Jones 22 Jun '04

22 Jun '04

| Well, it is certainly the case that in a denotational sense the | function is strict in h, because if h is bottom, the result is bottom. Right. And GHC's operational behaviour is faithful to the denotational semantics. When GHC compiles the program, if h is bottom, the call will not return. Simon | | But my operational understanding is that h is a projection, that is, | it is passed from argument to result unmodified. The demand on h | comes from the caller of the present function, which may or may not | be strict in that result. Thus, the function code itself here does | not force the evaluation of h. | | Regards, | Malcolm | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Understanding strictness of ghc output
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 13:30, Adrian Hey wrote: > I'm trying to figure out how you tell if ghc has correctly infered > strictness or whether or not a little more prompting from me > is needed. > > I tried compiling with -ddump-simpl, and I guess from looking > at this the DmdType bit is what I want (maybe). So if I have > "DmdType LS" for a function of arity 2, does this mean the > function is lazy in the first argument and strict in the second? > > I would be pretty confident that this was the correct interpretation, > but this is the Haskell code (from AVL library).. > > height :: AVL e -> Int > height = addHeight 0 where > addHeight h E = h > addHeight h (N l _ _) = addHeight h+2 l > addHeight h (Z l _ _) = addHeight h+1 l > addHeight h (P _ _ r) = addHeight h+2 r > > It seems pretty obvious to me that addHeight is strict in its > first argument if + is strict for Ints (as I guess it is). But this > gives "DmdType LS". Could you post the actual Core? I agree that addHeight looks strict in its first argument. Cheers, Simon

1 0

RE: can you block a thread in GHC by its threadID?
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 12:24, Volker Stolz wrote: > In local.glasgow-haskell-users, you wrote: >> On 22 June 2004 10:39, Bernard James POPE wrote: >>> Supposing that such a thing is indeed possible is there any chance >>> that it could be folded into GHC? (Then I wouldn't have to ship my >>> own variant of the runtime with buddha.) >> >> Certainly, I don't see any reason why not. It looks like a bolt-on >> extension rather than a global change. > > A similar feature has been *removed* from Java recently for a good > reason (rule of thumb: "If you used it, you did something wrong"). > OTOH I see that it's handy for debuggers. I bet the reason was that they don't have a good handle on asynchronous exceptions. But that raises a good point: it shouldn't be possible to stop a thread inside a block (i.e. Control.Exception.block). So stopThread should block until the target thread has actually stopped. This means adding the source thread to the blocked_exceptions list of the target thread. Cheers, Simon

1 0

RE: can you block a thread in GHC by its threadID?
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 10:39, Bernard James POPE wrote: > Supposing that such a thing is indeed possible is there any chance > that it could be folded into GHC? (Then I wouldn't have to ship my > own variant of the runtime with buddha.) Certainly, I don't see any reason why not. It looks like a bolt-on extension rather than a global change. Cheers, Simon

2 1

RE: can you block a thread in GHC by its threadID?
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 06:11, Bernard James POPE wrote: > Ideally I'd like this function: > > blockThread :: ThreadId -> IO () > > and thus: > > unBlockThread :: ThreadId -> IO () Hmm, might be possible. Can the blocked thread be woken up by an exception? (this is usually the case for blocked threads). Note that if you block a thread and then drop all references to it, the garbage collector will wake up the thread with a BlockedOnDeadMVar exception. I think I'd be tempted to call these functions {stop,continue}Thread to avoid overloading the block/unblock terms any more. Stop/continue is used in Unix land too. To implement this you'll need another StgTSOBlockReason state for stopped threads. Stopping already blocked threads might not be a problem, since (in some cases at least) the blocking operation will be retried when the thread is started again. I'm not sure whether this is always the case though. Stopping a thread blocked on a foreign call cannot be done. Stopping a thread blocked on I/O or delay# will need to remove the thread from the appropriate queue. You'll need two new primops: stopThread#, continueThread#. Take a look at the implementation of killThread# for clues (in ghc/rts/Exception.hc). Don't forget to take into account the case when a thread stops itself (that's the tricky one). Let us know if you need any more guidance... Cheers, Simon

2 1

can you block a thread in GHC by its threadID?
by Bernard James POPE 22 Jun '04

22 Jun '04

Hi again, Ideally I'd like this function: blockThread :: ThreadId -> IO () and thus: unBlockThread :: ThreadId -> IO () However I can see that there might be some tricky issues to resolve, such as what happens if you try to block an already blocked thread? Perhaps the return type could indicate whether the request to block succeeded, or if not why it failed. I'm not very familiar with Concurrent Haskell, so if you can see any pitfalls please point them out. Why do I want this? Again this is for my Haskell debugger. Basically I want the debuggee to run in its own thread. The user of the debugger should be able to request that the debuggee be suspended, do some debugging, and perhaps later resume the execution of the debuggee. If it helps for simplicity, assume that the debuggee doesn't fork its own threads --- although of course we'd have to support that situation also, eventually. Thus I want the debugger to act as a controlling thread that can influence the scheduling of the debuggee without the debuggee knowing anything about it. An alternative solution is to have the debuggee poll an MVar periodically, but I think this has obvious drawbacks. Cheers, Bernie.

2 2

RE: how to determine a programs memory usage at runtime?
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 03:51, Bernard James POPE wrote: > The mblocks_allocated variable should give me what I want. > > I think having access to this would also be useful to people who are > profiling their programs. You see a few papers where people want to > report how much memory their application needs, and having a > high-water mark is usually good enough. Beats trying to get the > information from top. Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI). Cheers, Simon

3 2

RE: how to determine a programs memory usage at runtime?
by Simon Marlow 21 Jun '04

21 Jun '04

On 21 June 2004 09:14, John Meacham wrote: > There might be some RTS calls to query the heap, but someone else is > probably more qualified to comment on that. The value of the mblocks_allocated variable in the RTS will give you the number of "megablocks" currently mmap()ed into the address space of the executable, which roughly equates to the amount of memory the program is using. A megablock is MBLOCK_SIZE bytes, currently 1Mb. Megablocks are never released, so this only gives you an upper limit for the amount of memory in use. Cheers, Simon

2 1