- ghc-devs - Haskell.org

Object unloading confusion
by Ömer Sinan Ağacan 16 Apr '20

16 Apr '20

Hi Simon, I'm looking at object unloading code in CheckUnload.c. My understanding of how unloading works is: - When unloading of an object is requested the object is added to `unloaded_objects`. - When `unloaded_objects` is not empty, after GC, we scan the heap for any references to objects. This is done in `searchHeapBlocks` called by `checkUnload`. - When `searchHeapBlocks` finds a reference to an object code it marks the object code. - After scanning the heap any objects in `unloaded_objects` that are not marked are unloaded. Does this sound right so far? What I'm confused about is `searchHeapBlocks`. As far as I can see it just skips all objects other than stacks. For example here's the code for scanning a constructor: case CONSTR: case CONSTR_NOCAF: case CONSTR_1_0: case CONSTR_0_1: case CONSTR_1_1: case CONSTR_0_2: case CONSTR_2_0: size = sizeW_fromITBL(info); break; So if I see a constructor with a reference to an object code in its payload I'll not mark the object code. This looks wrong to me. I don't understand why we only care about stacks and nothing else. Could you comment on this? Thanks, Ömer

2 2

T13456
by Simon Peyton Jones 16 Apr '20

16 Apr '20

Ben, Omer I find that when running the testsuite, I get the garbage below, for ghci/should_run/T13456. Adding an empty file T13456.stderr seems to fix it in one of my trees, but not in another. Very strange. Any ideas? Simon Framework failures: T13456.run T13456 [Traceback (most recent call last): File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 996, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1094, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1213, in ghci_script return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1638, in simple_run stderr=read_stderr(name), File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1808, in read_stderr return in_testdir(name, 'run.stderr').read_text(encoding='UTF-8') File "/usr/lib/python3.6/pathlib.py", line 1196, in read_text with self.open(mode='r', encoding=encoding, errors=errors) as f: File "/usr/lib/python3.6/pathlib.py", line 1183, in open opener=self._opener) File "/usr/lib/python3.6/pathlib.py", line 1037, in _opener return self._accessor.open(self, flags, mode) File "/usr/lib/python3.6/pathlib.py", line 387, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [Errno 2] No such file or directory: 'T13456.run/T13456.run.stderr' ] (ghci)

1 0

TcTypeNats
by Simon Peyton Jones 14 Apr '20

14 Apr '20

Sylvain TcTypeNats still exists in compiler/typecheck/ An omission? Simon

2 1

HsTick and HsBinTick
by Simon Peyton Jones 14 Apr '20

14 Apr '20

Friends I think HsTick and HsBinTick are added (only) by GHC.HsToCore.Coverage So I think the cannot occur in HsExpr GhcPs or HcExpr GhcRn If so we should change the data type decl to say this explicitly. Can anyone confirm or deny and add a ticket if so? Simon

3 2

scavenge_one failures on BCO objects
by chessai . 10 Apr '20

10 Apr '20

Hi devs, A coworker is experiencing sporadic failures when reloading our project in GHCi, with ``` ghc: internal error: scavenge_one: strange object 23 (GHC version 8.6.5 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: repl failed for mercury-web-backend-0.0.0. The build process terminated with exit code -6 ``` upon a quick inspection it seems that scavenge_one inspects the type of the object, but has no case for BCO (which is 23). I'm guessing there's something weird going on here since this doesn't happen deterministically. I don't have a good intuition for how this scavenging should work for BCO's, or if it should even be possible for BCO's to appear here (i.e. this is a symptom of some other bug). Any thoughts? Thanks

2 1

hadrian.settings recipes
by Ben Gamari 09 Apr '20

09 Apr '20

Hi everyone, As you may know, Hadrian's analogue to the make build system's mk/build.mk is hadrian.settings file. While the new mechanism is quite flexible, I often find myself having to look up recipes from previous builds to accomplish common tasks. To try to improve this situation I've started collecting the snippets I need most often on the Wiki [1]. I would invite anyone else who has something to add to do so. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#hadriansettings

1 0

Safe primops
by Simon Peyton Jones 09 Apr '20

09 Apr '20

Andreas, Simon, and other back-end-knowledgeable devs Can I draw your attention to this question? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3011#note_264584 It's about identifying which primops execute in-line without GC, and without thread-switching. Thanks Simon

1 0

Measuring compiler performance
by Simon Jakobi 08 Apr '20

08 Apr '20

Hi devs! I've recently started working on a few compiler perf related tickets, and wondered how to verify that a change actually has a positive impact on compiler performance. I first looked at the wiki for information on this, but didn't find much: https://gitlab.haskell.org/ghc/ghc/-/wikis/performance/compiler doesn't contain any information on how to measure compiler performance The best tip I found was the recommendation in https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-no-fib to compile nofib/spectral/simple/Main.hs. With -O0 and -O that takes respectively about 1.5s and 5s for me, so the effort is manageable. I've also done full nofib runs, but they take a very long time. A problem in this context is that reliable performance measurements require a quiet machine. Closing my browser, and turning off other programs is – in my perception – rather inconvenient, particularly when I have to do it for a prolonged time. Ideally I wouldn't have to perform these measurements on my local machine at all! Do you usually use a separate machine for this? _Very_ convenient would be some kind of bot whom I could tell e.g. @perf-bot compiler perf …or more concretely @perf-bot compile nofib/spectral/simple/Main.hs …or just @nofib-bot run … or something like that. I've noticed that CI now includes a perf-nofib job. But since it appears to run on a different machine each time, I'm not sure whether it's actually useful for comparing performance. Could it be made more useful by running it consistently on the same dedicated machine? Another question regarding performing compiler perf measurements locally is which build flavour to use: So far I have used the "perf" flavour. A problem here is that a full build seems to take close to an hour. A rebuild with --freeze1 takes ~15 minutes on my machine. Is this the right flavour to use? BTW what's the purpose of the profiled GHC modules built with this flavour which just seem to additionally prolong compile time? I don't see a ghc-prof binary or similar in _build/stage1/bin. Also, what's the status of gipeda? The most recent commit at https://perf.haskell.org/ghc/ is from "about a year ago"? Sorry for this load of questions and complaints! I do believe though that if work on compiler performance was a bit better documented and more convenient, we might see even more progress on that front. :) Cheers, Simon

6 7

Re: Uppercase OverloadedLabels
by Ryan Scott 08 Apr '20

08 Apr '20

No particular reason. There is an accepted GHC proposal to relax this restriction [1], as well as an accompanying GHC issue [2], but it has not yet been implemented. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-u… [2] https://gitlab.haskell.org/ghc/ghc/issues/11671

1 0

Targeting old Windows versions
by Andreas Klebinger 08 Apr '20

08 Apr '20

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage on versions of windows *older* than Windows 8.1/Sever 2012. Please let us know if you are targeting older versions than that either by responding to the mailing list, commenting on the ticket or contacting me directly if you have privacy concerns. Depending on how many people are affected by this change we might consider measures to reduce the impact. Cheers, Andreas

1 0