Broken Build due to T1969

Ömer Sinan Ağacan omeragacan at
Wed Aug 17 18:48:40 UTC 2016

I can't reproduce it on my x86_64 Linux laptop when I boot GHC HEAD with GHC

Anyway, feel free to revert 773e3aad (which disables the test) but I think
bumping the numbers a little bit is a better option here as that would at least
prevent things from getting worse.

I'm curious, does anyone know how much ram harbormaster has? I can't see from
the logs how many times GC is running during T1969, but maybe GC is running
less number of times which is causing the residency to increase.

I'm also wondering if there are more stable ways of testing residency. Can we
maybe do something like:

    runMajorGC >> printResidency

In some specific locations in the compiler and only look for those in perf
tests? Or does anyone have any better ideas?

2016-08-17 18:05 GMT+00:00 Ömer Sinan Ağacan <omeragacan at>:
> Hmm, it seems to be a 64bit Linux. Interestingly peak_megabytes_allocated is
> also different than numbers I'm getting on my 64bit Linux laptop. Maybe this is
> because harbormaster is booting with GHC 7.10.3 and I'm booting with GHC 8.0.1.
> I'm currently validating with 7.10.3 to see if I'll get the same numbers.
> 2016-08-17 15:17 GMT+00:00 Matthew Pickering <matthewtpickering at>:
>> I am just seeing it on harbourmaster.
>> Matt
>> On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan <omeragacan at> wrote:
>>> Ugh. I validated that patch before committing and validated many times after
>>> that patch. Are you using a 32bit system? Maybe we should bump the numbers for
>>> 32bit builds too.
>>> I'm hesitant to mark the test broken because I'm afraid that the numbers will
>>> increase if we stop testing for allocations/residency completely. I think
>>> temporarily bumping numbers is better than temporarily disabling it.
>>> What are the numbers you're getting?
>>> 2016-08-17 14:16 GMT+00:00 Matthew Pickering <matthewtpickering at>:
>>>> Hi all,
>>>> broke the build by re-enabling the test T1969
>>>> The ticket tracking this is:
>>>> Omer: Is it best to revert this patch and mark the test broken again?
>>>> Matt

More information about the ghc-devs mailing list