On 2015-09-14 18:05, Erik Joelsson wrote:
Hello,
When I implemented the heuristic to choose a suitable default
concurrency, I only ever worried about the build. I think having tests
use the same concurrency setting must be a new feature? In any case,
it seems like there is a case for reducing
nto troubles when reusing same concurrency
settings, even on high-end hardware. Without playing with timeouts
it's impossible to get a clean test sheet.
* on relatively high-end HW, current build concurrency settings seem
to be doing ok.
Realistically, I believe anything that uses more t
troubles when reusing same concurrency settings,
> even on high-end hardware. Without playing with timeouts it's impossible to
> get a clean test sheet.
> * on relatively high-end HW, current build concurrency settings seem to be
> doing ok.
>
> Realistically, I believe any
s run into troubles when reusing same concurrency
settings, even on high-end hardware. Without playing with timeouts
it's impossible to get a clean test sheet.
* on relatively high-end HW, current build concurrency settings seem
to be doing ok.
Realistically, I believe anything that use
when reusing same concurrency
settings, even on high-end hardware. Without playing with timeouts it's
impossible to get a clean test sheet.
* on relatively high-end HW, current build concurrency settings seem to
be doing ok.
Realistically, I believe anything that uses more than n
On 14/09/2015 17:05, Erik Joelsson wrote:
Hello,
When I implemented the heuristic to choose a suitable default
concurrency, I only ever worried about the build. I think having tests
use the same concurrency setting must be a new feature? In any case,
it seems like there is a case for reduci
Hello,
When I implemented the heuristic to choose a suitable default
concurrency, I only ever worried about the build. I think having tests
use the same concurrency setting must be a new feature? In any case, it
seems like there is a case for reducing concurrency when running tests.
Another
As I said, building/compiling is not the issue - but when running CPU
intensive tests you are bound to see spurious failures (I see at least 2
regular ones in langtools tests).
Maurizio
On 14/09/15 12:06, Andrew Haley wrote:
On 09/14/2015 12:03 PM, Maurizio Cimadamore wrote:
why the default
The information I posted was slightly incorrect, sorry - my machine has
8 cores (and 16 virtual processors) - so you see why choosing
concurrency factor of 14 is particularly bad in this setup.
Maurizio
On 14/09/15 12:03, Maurizio Cimadamore wrote:
Hi,
I realized that the concurrency factor i
On 09/14/2015 12:03 PM, Maurizio Cimadamore wrote:
> why the default parameter is set to such aggressive value?
It works great when compiling, as long as your memory interface is
fast enough.
Andrew.
Hi,
I realized that the concurrency factor inferred by the JDK build might
be too high; on a 16 core machine, concurrency is set to 14 - which then
leads to absurd load averages (50-ish) when building/running tests. High
load when building is not a big issue, but when running test this almost
11 matches
Mail list logo
