Fixed memory leak associated with TLS.

Fixed memory leak associated with TLS.

We used to allocate thread-local memory on each compile.
If the compile did not happen on the same thread as ShInitialize,
we leaked the thread-local memory.

It turns out that there is no need to allocate any thread-local
memory. This patch cleans up all the unnecessary junk around TLS.

BUG=crbug.com/181691
R=kbr@chromium.org

Committed: https://code.google.com/p/angleproject/source/detail?r=688f78a

[earthdok, 2013-07-24 18:06:38]

On 2013/07/24 17:34:34, Alok Priyadarshi wrote:

I might be doing something wrong, but when I synced Chromium's
third_party/angle, applied this patch and recompiled cc_unittests, the leaks
were still there.

[Alok Priyadarshi, 2013-07-24 18:34:45]

On 2013/07/24 18:06:38, earthdok wrote:
> On 2013/07/24 17:34:34, Alok Priyadarshi wrote:
> 
> I might be doing something wrong, but when I synced Chromium's
> third_party/angle, applied this patch and recompiled cc_unittests, the leaks
> were still there.

angle is now synced into third_party/angle_dx11. Can you try patching that?

[earthdok, 2013-07-24 18:39:10]

On 2013/07/24 18:34:45, Alok Priyadarshi wrote:
> On 2013/07/24 18:06:38, earthdok wrote:
> > On 2013/07/24 17:34:34, Alok Priyadarshi wrote:
> > 
> > I might be doing something wrong, but when I synced Chromium's
> > third_party/angle, applied this patch and recompiled cc_unittests, the leaks
> > were still there.
> 
> angle is now synced into third_party/angle_dx11. Can you try patching that?

Yep - that fixes the leaks.

[kbr1, 2013-07-26 01:03:20]

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll.cpp
File src/compiler/InitializeDll.cpp (right):

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll....
src/compiler/InitializeDll.cpp:31: FreePoolIndex();
Doesn't this just free the TLS indices associated with the thread on which
DetachProcess is called? What about any other threads which performed compiles?

[Alok Priyadarshi, 2013-07-26 04:20:22]

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll.cpp
File src/compiler/InitializeDll.cpp (right):

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll....
src/compiler/InitializeDll.cpp:31: FreePoolIndex();
On 2013/07/26 01:03:20, kbr1 wrote:
> Doesn't this just free the TLS indices associated with the thread on which
> DetachProcess is called? What about any other threads which performed
compiles?

The index is per-process. We no longer do any allocation per thread - just store
thread-specific values into the index.

[kbr1, 2013-07-29 22:56:17]

LGTM

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll.cpp
File src/compiler/InitializeDll.cpp (right):

https://codereview.appspot.com/11679046/diff/3001/src/compiler/InitializeDll....
src/compiler/InitializeDll.cpp:31: FreePoolIndex();
On 2013/07/26 04:20:22, Alok Priyadarshi wrote:
> On 2013/07/26 01:03:20, kbr1 wrote:
> > Doesn't this just free the TLS indices associated with the thread on which
> > DetachProcess is called? What about any other threads which performed
> compiles?
> 
> The index is per-process. We no longer do any allocation per thread - just
store
> thread-specific values into the index.

Thanks. Sorry about my previous misunderstanding -- was in a rush during the
review.

I don't fully understand the statement that the code no longer does any
allocation per thread -- I assume you mean that it doesn't allocate any wrapper
data structure for things like the TParseContext and TPoolAllocator. Anyway,
assuming this has been tested, looks fine.

[Alok Priyadarshi, 2013-07-29 23:32:47]

Committed patchset #2 manually as r688f78a (presubmit successful).