Remove dependency on allocator from 'content' targets

Remove dependency on allocator from 'content' targets

Current content targets that are libraries depend on allocator. Only the
final executable should decide the allocator. More over this would
create two copies of tcmalloc library in linux in shared library build,
one from content and one from the chrome executable
(target:chrome_initial).
This Cl removes the dependency from content, and creates a shim layer
for tcmalloc that is built in allocator target, which will be
included by the executable. This is done by creating a weak function
which will be replaced by the shim layer.

Many places in code uses the tcmalloc functions for reasons like,
getting stats or managing heap profiler. Some use allocator_extension,
while other use the functions directly by depending on tcmalloc. All
these have been redirected to use the allocator_extension in base, and
this is initialized using the weak function described above and some
clean-up of allocator extension.

This CL does not actually remove the dependency in gyp and gn build
files since there are other targets that depend on content and all
these executables should be added with allocator dependency. So, it
will be added in seperate CL.

I am still not sure if the allocator_extension_thunks target is
even necessary. This will be cleaned-up in follow up CLs.

BUG=

[ssid, 2015-11-23 11:42:07]

Description was changed from

==========
Remove dependency on allocator from 'content' targets

Current content targets that are libraries depend on allocator. Only the
final executable should decide the allocator. More over this would
create two copies of tcmalloc library in linux in shared library build,
one from content and one from the chrome executable
(target:chrome_initial).
This Cl removes the dependency from content, and creates a shim layer
for tcmalloc that is built in allocator target, which will be
included by the executable. This is done by creating a weak function
which will be replaced by the shim layer.

Many places in code uses the tcmalloc functions for reasons like,
getting stats or managing heap profiler. All these have been redirected
to use the allocator_extension in base, and this is initialized using
the weak function described above.

This CL does not actually remove the dependency in gyp and gn build
files since there are other targets that depend on content and all
these executables should be added with allocator dependency. So, it
will be added in seperate CL.

BUG=
==========

to

==========
Remove dependency on allocator from 'content' targets

Current content targets that are libraries depend on allocator. Only the
final executable should decide the allocator. More over this would
create two copies of tcmalloc library in linux in shared library build,
one from content and one from the chrome executable
(target:chrome_initial).
This Cl removes the dependency from content, and creates a shim layer
for tcmalloc that is built in allocator target, which will be
included by the executable. This is done by creating a weak function
which will be replaced by the shim layer.

Many places in code uses the tcmalloc functions for reasons like,
getting stats or managing heap profiler. Some use allocator_extension,
while other use the functions directly by depending on tcmalloc. All
these have been redirected to use the allocator_extension in base, and
this is initialized using the weak function described above and some
clean-up of allocator extension.

This CL does not actually remove the dependency in gyp and gn build
files since there are other targets that depend on content and all
these executables should be added with allocator dependency. So, it
will be added in seperate CL.

BUG=
==========

[ssid, 2015-11-23 11:45:47]

Description was changed from

==========
Remove dependency on allocator from 'content' targets

Current content targets that are libraries depend on allocator. Only the
final executable should decide the allocator. More over this would
create two copies of tcmalloc library in linux in shared library build,
one from content and one from the chrome executable
(target:chrome_initial).
This Cl removes the dependency from content, and creates a shim layer
for tcmalloc that is built in allocator target, which will be
included by the executable. This is done by creating a weak function
which will be replaced by the shim layer.

Many places in code uses the tcmalloc functions for reasons like,
getting stats or managing heap profiler. Some use allocator_extension,
while other use the functions directly by depending on tcmalloc. All
these have been redirected to use the allocator_extension in base, and
this is initialized using the weak function described above and some
clean-up of allocator extension.

This CL does not actually remove the dependency in gyp and gn build
files since there are other targets that depend on content and all
these executables should be added with allocator dependency. So, it
will be added in seperate CL.

BUG=
==========

to

==========
Remove dependency on allocator from 'content' targets

Current content targets that are libraries depend on allocator. Only the
final executable should decide the allocator. More over this would
create two copies of tcmalloc library in linux in shared library build,
one from content and one from the chrome executable
(target:chrome_initial).
This Cl removes the dependency from content, and creates a shim layer
for tcmalloc that is built in allocator target, which will be
included by the executable. This is done by creating a weak function
which will be replaced by the shim layer.

Many places in code uses the tcmalloc functions for reasons like,
getting stats or managing heap profiler. Some use allocator_extension,
while other use the functions directly by depending on tcmalloc. All
these have been redirected to use the allocator_extension in base, and
this is initialized using the weak function described above and some
clean-up of allocator extension.

This CL does not actually remove the dependency in gyp and gn build
files since there are other targets that depend on content and all
these executables should be added with allocator dependency. So, it
will be added in seperate CL.

I am still not sure if the allocator_extension_thunks target is
even necessary. This will be cleaned-up in follow up CLs.

BUG=
==========

[ssid, 2015-11-23 13:22:33]

ssid@chromium.org changed reviewers:
+ brettw@chromium.org, wfh@chromium.org

[ssid, 2015-11-23 13:22:33]

+brettw
+wfh
PTAL.
Background context: We are trying to introduce a shim layer for allocator in all
platforms, for a heap profiler in memory-infra. As first step I am trying to
clean up dependency on the allocator target and make sure only executables
depend on allcoator.

[Primiano Tucci (use gerrit), 2015-11-25 12:03:09]

primiano@chromium.org changed reviewers:
+ primiano@chromium.org

[Primiano Tucci (use gerrit), 2015-11-25 12:47:17]

temporarily removing wfh and brett.

Rationale: I see what's going on here (layering being violated and worse, ODR
being violated in component builds) and overall this make sense.

However, before making this change I think we want to have a broader discussion
on chromium-dev (and/or write down a short summary doc) to make sure that there
aren't use cases we are not considering, and generally to explain what's going
on here.

I'll take a look to this in more details and than start a doc+discussion.
Will readd OWN

https://codereview.chromium.org/1469843002/diff/20001/base/allocator/allocato...
File base/allocator/allocator_extension.cc (right):

https://codereview.chromium.org/1469843002/diff/20001/base/allocator/allocato...
base/allocator/allocator_extension.cc:17: // library. The executable target is
expected include an allocator shim layer
remove "shim layer"

https://codereview.chromium.org/1469843002/diff/20001/base/allocator/allocato...
File base/allocator/allocator_extension.h (right):

https://codereview.chromium.org/1469843002/diff/20001/base/allocator/allocato...
base/allocator/allocator_extension.h:17: // Initializes the allocator and the
routes the extension functions
"the routes the extension functions implementations to base?"

[Primiano Tucci (use gerrit), 2015-11-25 12:47:24]

primiano@chromium.org changed reviewers:
- brettw@chromium.org, wfh@chromium.org

[Primiano Tucci (use gerrit), 2015-11-25 12:49:48]

primiano@chromium.org changed reviewers:
+ brettw@chromium.org, wfh@chromium.org

[Primiano Tucci (use gerrit), 2015-11-25 12:49:48]

Ehm pressed enter to soon.

The last statement was intended to be
"Will re-add OWNERS once we had a broader discussion."

[Primiano Tucci (use gerrit), 2015-11-25 12:49:58]

primiano@chromium.org changed reviewers:
- brettw@chromium.org, wfh@chromium.org