Fixes the regression caused by 7568e1f18e.

Fixes the regression caused by 7568e1f18e.

The IO tests unscheduled the mutator thread constantly, forcing the
isolate to fill new space and cause a GC.

Now, the mutator thread keeps its TLAB when unscheduled, taking
advantage of the fact the same thread object will always be the
mutator thread.

R=asiva@google.com, rmacnak@google.com

Committed: https://github.com/dart-lang/sdk/commit/479db734e339060fcdfd98154d5dc39b1285bc66

[danunez, 2017-08-07 19:57:52]

Golem reports little change in comparison to the build BEFORE my CL on Saturday:
http://146.148.43.81:8080/Comparison?team=dart-vm#targetA%3Ddart%3BmachineTyp...

Golem reports positive change in comparison to the CL I landed on Saturday:
http://146.148.43.81:8080/Comparison?team=dart-vm#targetA%3Ddart%3BmachineTyp...

[rmacnak, 2017-08-07 21:29:36]

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/isolate.cc
File runtime/vm/isolate.cc (right):

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/isolate.cc#newco...
runtime/vm/isolate.cc:2577: if ((Dart::vm_isolate() != NULL) &&
Isn't this always a no-op now? Either the Thread still has 0/0 from when it was
constructed, has 0/0 from losing its TLAB in a GC, or has a TLAB we're going to
keep.

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/scavenger.cc
File runtime/vm/scavenger.cc (right):

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/scavenger.cc#new...
runtime/vm/scavenger.cc:799: Thread* mutator_thread = isolate->mutator_thread();
It looks like isolate->mutator_thread_ is NULL while the mutator is unscheduled,
but we still want to invalidate its TLAB.

Siva, any thoughts on reaching into the ThreadRegistery versus not clearing
isolate->mutator_thread_ ?

[danunez, 2017-08-07 23:09:59]

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/isolate.cc
File runtime/vm/isolate.cc (right):

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/isolate.cc#newco...
runtime/vm/isolate.cc:2577: if ((Dart::vm_isolate() != NULL) &&
On 2017/08/07 21:29:35, rmacnak wrote:
> Isn't this always a no-op now? Either the Thread still has 0/0 from when it
was
> constructed, has 0/0 from losing its TLAB in a GC, or has a TLAB we're going
to
> keep.

This is a no-op. This will be deleted.

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/scavenger.cc
File runtime/vm/scavenger.cc (right):

https://codereview.chromium.org/2993863002/diff/1/runtime/vm/scavenger.cc#new...
runtime/vm/scavenger.cc:799: Thread* mutator_thread = isolate->mutator_thread();
On 2017/08/07 21:29:35, rmacnak wrote:
> It looks like isolate->mutator_thread_ is NULL while the mutator is
unscheduled,
> but we still want to invalidate its TLAB.
> 
> Siva, any thoughts on reaching into the ThreadRegistery versus not clearing
> isolate->mutator_thread_ ?

It looks like isolate->mutator_thread() returns the one cached in
ThreadRegistry. Therefore, we have access to the mutator_thread and its TLAB
until ThreadRegistry itself is destroyed.

[rmacnak, 2017-08-07 23:27:22]

lgtm

[danunez, 2017-08-08 17:17:21]

Description was changed from

==========
Fixes the regression caused by 7568e1f18e.

The IO tests unscheduled the mutator thread constantly, forcing the
isolate to fill new space and cause a GC.

Now, the mutator thread keeps its TLAB when unscheduled, taking
advantage of the fact the same thread object will always be the
mutator thread.

R=rmacnak@google.com,asiva@google.com
==========

to

==========
Fixes the regression caused by 7568e1f18e.

The IO tests unscheduled the mutator thread constantly, forcing the
isolate to fill new space and cause a GC.

Now, the mutator thread keeps its TLAB when unscheduled, taking
advantage of the fact the same thread object will always be the
mutator thread.

R=asiva@google.com, rmacnak@google.com

Committed:
https://github.com/dart-lang/sdk/commit/479db734e339060fcdfd98154d5dc39b1285bc66
==========

[danunez, 2017-08-08 17:17:24]

Committed patchset #2 (id:20001) manually as
479db734e339060fcdfd98154d5dc39b1285bc66 (presubmit successful).