Update status for html/JsArray test, increase dart2js timeout on browser bots.

Update status for html/JsArray test, increase dart2js timeout on browser bots.

BUG=https://github.com/dart-lang/sdk/issues/26060
BUG=https://github.com/dart-lang/sdk/issues/26197
R=kustermann@google.com

Committed: https://github.com/dart-lang/sdk/commit/82e62563924c0bfde5be8dccfddb186980de637f

[Bill Hesse, 2016-04-06 13:50:02]

whesse@google.com changed reviewers:
+ kustermann@google.com

[kustermann, 2016-04-06 13:55:58]

LGTM

[Bill Hesse, 2016-04-06 13:57:40]

Description was changed from

==========
Update status for html/JsArray test, increase dart2js timeout on browser bots.

BUG=https://github.com/dart-lang/sdk/issues/26060
BUG=https://github.com/dart-lang/sdk/issues/26197
==========

to

==========
Update status for html/JsArray test, increase dart2js timeout on browser bots.

BUG=https://github.com/dart-lang/sdk/issues/26060
BUG=https://github.com/dart-lang/sdk/issues/26197
R=kustermann@google.com

Committed:
https://github.com/dart-lang/sdk/commit/82e62563924c0bfde5be8dccfddb186980de637f
==========

[Bill Hesse, 2016-04-06 13:57:42]

Committed patchset #1 (id:1) manually as
82e62563924c0bfde5be8dccfddb186980de637f (presubmit successful).

[ahe, 2016-04-06 14:41:47]

ahe@google.com changed reviewers:
+ ahe@google.com

[ahe, 2016-04-06 14:41:47]

I don't understand this. You've implemented what is supposed to solve this
issue, so why work around it?

Also, wouldn't it be more reliable to simply run one browser until your more
general solution is landed?

[Bill Hesse, 2016-04-06 14:48:02]

On 2016/04/06 14:41:47, ahe wrote:
> I don't understand this. You've implemented what is supposed to solve this
> issue, so why work around it?
> 
> Also, wouldn't it be more reliable to simply run one browser until your more
> general solution is landed?

The cl that slowed down (by serializing) the browser startups solved the problem
in almost all cases, but there were a few remaining sticky timeouts.
This should make them actually report the time they take,
and let us try other methods of reducing the load, to see the effect it has on
the compilation times.

I'm not sure that the browser is the problem, anymore.  I suspect these could be
the first runs
of the dart2js compiler, before it is warmed up.

[ahe, 2016-04-06 18:41:55]

On 2016/04/06 14:48:02, Bill Hesse wrote:
> On 2016/04/06 14:41:47, ahe wrote:
> > I don't understand this. You've implemented what is supposed to solve this
> > issue, so why work around it?
> > 
> > Also, wouldn't it be more reliable to simply run one browser until your more
> > general solution is landed?
> 
> The cl that slowed down (by serializing) the browser startups solved the
problem
> in almost all cases, but there were a few remaining sticky timeouts.
> This should make them actually report the time they take,
> and let us try other methods of reducing the load, to see the effect it has on
> the compilation times.
> 
> I'm not sure that the browser is the problem, anymore.  I suspect these could
be
> the first runs
> of the dart2js compiler, before it is warmed up.

If the problem is dart2js startup, why are you allowing browsers to be slower?

[Bill Hesse, 2016-04-06 20:52:30]

On 2016/04/06 18:41:55, ahe wrote:
> On 2016/04/06 14:48:02, Bill Hesse wrote:
> > On 2016/04/06 14:41:47, ahe wrote:
> > > I don't understand this. You've implemented what is supposed to solve this
> > > issue, so why work around it?
> > > 
> > > Also, wouldn't it be more reliable to simply run one browser until your
more
> > > general solution is landed?
> > 
> > The cl that slowed down (by serializing) the browser startups solved the
> problem
> > in almost all cases, but there were a few remaining sticky timeouts.
> > This should make them actually report the time they take,
> > and let us try other methods of reducing the load, to see the effect it has
on
> > the compilation times.
> > 
> > I'm not sure that the browser is the problem, anymore.  I suspect these
could
> be
> > the first runs
> > of the dart2js compiler, before it is warmed up.
> 
> If the problem is dart2js startup, why are you allowing browsers to be slower?

I thought it was browser startup, at the same time as dart2js running.  I still
think that was the biggest problem, since
most of the timeouts (of dart2js) disappeared after making the change.  I'm now
thinking that the remaining ones might
be the first runs of dart2js, or may be actual hangs, since they now all seem to
time out after 2 minutes.

[ahe, 2016-04-07 07:43:15]

On 2016/04/06 20:52:30, Bill Hesse wrote:
> On 2016/04/06 18:41:55, ahe wrote:
> > On 2016/04/06 14:48:02, Bill Hesse wrote:
> > > On 2016/04/06 14:41:47, ahe wrote:
> > > > I don't understand this. You've implemented what is supposed to solve
this
> > > > issue, so why work around it?
> > > > 
> > > > Also, wouldn't it be more reliable to simply run one browser until your
> more
> > > > general solution is landed?
> > > 
> > > The cl that slowed down (by serializing) the browser startups solved the
> > problem
> > > in almost all cases, but there were a few remaining sticky timeouts.
> > > This should make them actually report the time they take,
> > > and let us try other methods of reducing the load, to see the effect it
has
> on
> > > the compilation times.
> > > 
> > > I'm not sure that the browser is the problem, anymore.  I suspect these
> could
> > be
> > > the first runs
> > > of the dart2js compiler, before it is warmed up.
> > 
> > If the problem is dart2js startup, why are you allowing browsers to be
slower?
> 
> I thought it was browser startup, at the same time as dart2js running.  I
still
> think that was the biggest problem, since
> most of the timeouts (of dart2js) disappeared after making the change.  I'm
now
> thinking that the remaining ones might
> be the first runs of dart2js, or may be actual hangs, since they now all seem
to
> time out after 2 minutes.

I'm still not understanding why you're adding a special timeout value to
browsers?

Here's my guess as to what is going on:

1. Starting N browsers at the same time can cause some timeouts. You've solved
that, and thus there should be no need to add a special browser timeout delay.

2. Running more than N processes when you only have N cores may starve some
processes.

3. There's potentially other timeout problems that have been hidden by the
browser startup problem.

I don't see how adding an additional browser delay is solving anything, but
reducing the number of tasks (option -j) should work if my guess is correct.