[oilpan] Remove ThreadAffinity::MainThreadOnly

[oilpan] Remove ThreadAffinity::MainThreadOnly

[haraken, 2013-12-12 06:33:46]

PTAL.

- May I land this CL to observe results of perf bots? If I observe some
regression, I'll revert the CL.

- When upstreaming Oilpan, I suggest not using REQUIRE_THREADSAFE_HANDLES macros
at first. We can introduce the macros when we observe some regression in
practice.

https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h
File Source/heap/ThreadState.h (right):

https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h#ne...
Source/heap/ThreadState.h:231: if (LIKELY(s_mainThreadStackTop < &dummy &&
&dummy <= s_mainThreadStackBottom))

Of a couple of approaches I have tried, this is the best approach in terms of
performance.

In Linux, I cannot observe any regression in Dromaeo:

dom-attr: 1056 => 1057 runs/sec
dom-modify: 537 => 526 runs/sec
dom-query: 28458 => 28285 runs/sec
dom-traverse: 649 => 654 runs/sec

We might observe a bit regression in Windows because MSVC doesn't make
optimization for LIKELY.

[Mads Ager (chromium), 2013-12-12 06:51:56]

https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h
File Source/heap/ThreadState.h (right):

https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h#ne...
Source/heap/ThreadState.h:231: if (LIKELY(s_mainThreadStackTop < &dummy &&
&dummy <= s_mainThreadStackBottom))
On 2013/12/12 06:33:47, haraken wrote:
> 
> Of a couple of approaches I have tried, this is the best approach in terms of
> performance.
> 
> In Linux, I cannot observe any regression in Dromaeo:
> 
> dom-attr: 1056 => 1057 runs/sec
> dom-modify: 537 => 526 runs/sec
> dom-query: 28458 => 28285 runs/sec
> dom-traverse: 649 => 654 runs/sec
> 
> We might observe a bit regression in Windows because MSVC doesn't make
> optimization for LIKELY.

I find this rather nasty. It is probably true that there is always 64k of stack
space below the initial point but it is a magic number. Also, it means that on
the main thread you all of a sudden start going through thread-local storage if
you recurse very deeply. Can you share the numbers if you always to through
thread-local storage. I would prefer if we can either know precisely that we are
on the main thread or always go through thread-local storage.

[haraken, 2013-12-12 07:06:21]

On 2013/12/12 06:51:56, Mads Ager (chromium) wrote:
> https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h
> File Source/heap/ThreadState.h (right):
> 
>
https://codereview.chromium.org/113693002/diff/1/Source/heap/ThreadState.h#ne...
> Source/heap/ThreadState.h:231: if (LIKELY(s_mainThreadStackTop < &dummy &&
> &dummy <= s_mainThreadStackBottom))
> On 2013/12/12 06:33:47, haraken wrote:
> > 
> > Of a couple of approaches I have tried, this is the best approach in terms
of
> > performance.
> > 
> > In Linux, I cannot observe any regression in Dromaeo:
> > 
> > dom-attr: 1056 => 1057 runs/sec
> > dom-modify: 537 => 526 runs/sec
> > dom-query: 28458 => 28285 runs/sec
> > dom-traverse: 649 => 654 runs/sec
> > 
> > We might observe a bit regression in Windows because MSVC doesn't make
> > optimization for LIKELY.
> 
> I find this rather nasty. It is probably true that there is always 64k of
stack
> space below the initial point but it is a magic number. Also, it means that on
> the main thread you all of a sudden start going through thread-local storage
if
> you recurse very deeply. Can you share the numbers if you always to through
> thread-local storage. I would prefer if we can either know precisely that we
are
> on the main thread or always go through thread-local storage.

Yeah, I want to get the number, but I don't have a windows machine... I
confirmed that there is no regression in Linux 64-bit (because thread-local
storage in Linux is very fast), but it won't tell anything about windows
results.

I uploaded a CL that always uses thread-local storage to the patch set 3. Would
anyone test it in windows?

[Erik Corry, 2013-12-12 07:33:10]

ISTR that Mac is slowest at thread local storage, so unless we have a Mac
perf bot this excercise will not tell us what we need to know.


On Thu, Dec 12, 2013 at 8:06 AM, <haraken@chromium.org> wrote:

> On 2013/12/12 06:51:56, Mads Ager (chromium) wrote:
>
>> https://codereview.chromium.org/113693002/diff/1/Source/
>> heap/ThreadState.h
>> File Source/heap/ThreadState.h (right):
>>
>
>
> https://codereview.chromium.org/113693002/diff/1/Source/
> heap/ThreadState.h#newcode231
>
>> Source/heap/ThreadState.h:231: if (LIKELY(s_mainThreadStackTop < &dummy &&
>> &dummy <= s_mainThreadStackBottom))
>> On 2013/12/12 06:33:47, haraken wrote:
>> >
>> > Of a couple of approaches I have tried, this is the best approach in
>> terms
>>
> of
>
>> > performance.
>> >
>> > In Linux, I cannot observe any regression in Dromaeo:
>> >
>> > dom-attr: 1056 => 1057 runs/sec
>> > dom-modify: 537 => 526 runs/sec
>> > dom-query: 28458 => 28285 runs/sec
>> > dom-traverse: 649 => 654 runs/sec
>> >
>> > We might observe a bit regression in Windows because MSVC doesn't make
>> > optimization for LIKELY.
>>
>
>  I find this rather nasty. It is probably true that there is always 64k of
>>
> stack
>
>> space below the initial point but it is a magic number. Also, it means
>> that on
>> the main thread you all of a sudden start going through thread-local
>> storage
>>
> if
>
>> you recurse very deeply. Can you share the numbers if you always to
>> through
>> thread-local storage. I would prefer if we can either know precisely that
>> we
>>
> are
>
>> on the main thread or always go through thread-local storage.
>>
>
> Yeah, I want to get the number, but I don't have a windows machine... I
> confirmed that there is no regression in Linux 64-bit (because thread-local
> storage in Linux is very fast), but it won't tell anything about windows
> results.
>
> I uploaded a CL that always uses thread-local storage to the patch set 3.
> Would
> anyone test it in windows?
>
>
> https://codereview.chromium.org/113693002/
>



-- 
Erik Corry, Software Engineer
Google Denmark ApS - Frederiksborggade 20B, 1 sal,
1360 København K - Denmark - CVR nr. 28 86 69 84

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[haraken, 2013-12-12 07:41:44]

> ISTR that Mac is slowest at thread local storage, so unless we have a Mac
> perf bot this excercise will not tell us what we need to know.

I'd guess that running Dromaeo with the patch set 3 in Mac will tell us rough
estimation about the regression. (If you have a Mac environment now, I'd be
happy if you could try the patch. (Sorry again, my Mac machine is out-dated and
not working now...))

[Mads Ager (chromium), 2013-12-12 07:44:13]

Unfortunately, after upgrading to Mavericks I cannot build the branch
anymore so I'm afraid it will be hard to get numbers on Mac for this at
this point in time. :(


On Thu, Dec 12, 2013 at 8:41 AM, <haraken@chromium.org> wrote:

> ISTR that Mac is slowest at thread local storage, so unless we have a Mac
>> perf bot this excercise will not tell us what we need to know.
>>
>
> I'd guess that running Dromaeo with the patch set 3 in Mac will tell us
> rough
> estimation about the regression. (If you have a Mac environment now, I'd be
> happy if you could try the patch. (Sorry again, my Mac machine is
> out-dated and
> not working now...))
>
>
> https://codereview.chromium.org/113693002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.