Count constraint-solving memory more precisely, rdar://29684330

[graydon]

The type constraint solver guides some of its thinking about when to give up on a
sub-problem by measuring its use of memory. Unfortunately it wasn't measuring that
number very accurately, which meant that it kept going far longer than it should have
on certain cases (and chewed up far too much real memory in the process).

This fixes two points of mis-measurement: the solver-arena's bump allocator (which isn't
actually counted in the existing getTotalMemory call) and, more critically, the cost of
the vector of solutions being accumulated itself.

rdar://29684330

[graydon]

The second bit of accounting here is perhaps debatable, and I'd appreciate conceptual double-checking by someone who has thought longer about this. It seems to me that it's more truthy to consider this (very large) temporary vector-of-objects it's building as "part of" the solver's memory use, but an argument could be made the other way.

In any case it seems to behave much better with this patch!

[rudkx]

I added a new metric that is enabled when !Swift3, and I think we need to look at making sure these issues are fixed on that path as well. A couple things I noticed when I was debugging one of these cases (but didn't have a chance to really look into in detail):

• The value TypeCounter in ConstraintSystem was really large despite not having that many type variables, so there might be something wrong with my new metric, or something wrong with how TypeCounter is getting incremented.
• CountScopes was not increasing despite the fact that we were allocating a bunch of memory in gatherConstraints(), which leads me to believe that perhaps we were just spinning somewhere rather than actively making progress in the solver. If that's the case the new metric might need to be tweaked for these cases as well.

Can you take a look at that path and see what's happening?

[DougGregor]

This generally looks good, but aren't we still missing the distinction between "failed because I found no solutions" and "failed because I hit a threshold"?

[graydon]

Updated with memory high-water mark to at least make the memory-pressure-based judgment sticky; this means it now reports "too complex" properly in both swift 3 and 4 modes.

Re: feedback from @DougGregor, yes, it seems that the existing system doesn't differentiate those cases in the return codes, but it does check the "too-complex-ness" of an unsolved constraint system during salvage, when revisiting it in CSDiag. I just needed to make that property sticky so that it doesn't get judged too-complex in CSSolver and not-too-complex in CSDiag.

Will try looking into the questions @rudkx asks above wrt. the non-memory signals. Initial scan of -debug-constraint logs looks like we're just "not quite hitting the thresholds"; around 200 type variables and only a few thousand scopes. Lowering the scope threshold to a few thousand means it errors out, for example. The problem is that it's allocating gigabytes of memory along the way, accumulating solutions. I'll try to characterize the workload in the associated testcase a little better but I'm still rather unclear on how the solver works. Learning while I go.

Meanwhile, running tests!

[graydon]

@swift-ci please smoke test

[graydon]

@swift-ci please test

[swift-ci]

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - b92006467751cceecfe565c603743b6b81d915aa
Test requested by - @graydon

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - b92006467751cceecfe565c603743b6b81d915aa
Test requested by - @graydon

[rudkx]

LGTM.

Thanks for looking into this!

[graydon]

@swift-ci please smoke test and merge

[graydon]

@swift-ci please smoke test and merge