Make ui_tests (and any renderer-based PE) use tcmalloc....

Make ui_tests (and any renderer-based PE) use tcmalloc.

This paves the way for some upcoming allocator improvements

BUG=none
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=25603

[Mike Belshe, 2009-09-07 17:07:35]

We're going to add some hooks for the renderer to use some additional allocator
functionality; as such, anything that links the renderer needs to use tcmalloc.

I'm going to do a test checkin today (while its a holiday) to see how the tests
hold up.  I'll back out.

[Anton Muhin, 2009-09-07 17:19:07]

LGTM, but that didn't compile that way for me: the problem was with
conflicting definitions coming from LIBCMTD.  I had to inject several
export_dependent_settings (for some reason declare_dependency_setting
didn't work).

yours,
anton.

On Mon, Sep 7, 2009 at 9:07 PM, <mbelshe@chromium.org> wrote:
> Reviewers: sgk,
>
> Message:
> We're going to add some hooks for the renderer to use some additional
> allocator functionality; as such, anything that links the renderer needs
> to use tcmalloc.
>
> I'm going to do a test checkin today (while its a holiday) to see how
> the tests hold up. =A0I'll back out.
>
> Description:
> Make ui_tests (and any renderer-based PE) use tcmalloc.
>
> This paves the way for some upcoming allocator improvements
>
> BUG=3Dnone
> TEST=3Dnone
>
>
> Please review this at http://codereview.chromium.org/199041
>
> SVN Base: svn://chrome-svn/chrome/trunk/src/
>
> Affected files:
> =A0M =A0 =A0 chrome/chrome.gyp
>
>
>

[Mike Belshe, 2009-09-07 19:08:37]

Right - this change is dependent on

http://codereview.chromium.org/200036

to fix the problem you mention for debug builds.

Mike


On 2009/09/07 17:19:07, antonm_google.com wrote:
> LGTM, but that didn't compile that way for me: the problem was with
> conflicting definitions coming from LIBCMTD.  I had to inject several
> export_dependent_settings (for some reason declare_dependency_setting
> didn't work).
> 
> yours,
> anton.
> 
> On Mon, Sep 7, 2009 at 9:07 PM, <mailto:mbelshe@chromium.org> wrote:
> > Reviewers: sgk,
> >
> > Message:
> > We're going to add some hooks for the renderer to use some additional
> > allocator functionality; as such, anything that links the renderer needs
> > to use tcmalloc.
> >
> > I'm going to do a test checkin today (while its a holiday) to see how
> > the tests hold up. =A0I'll back out.
> >
> > Description:
> > Make ui_tests (and any renderer-based PE) use tcmalloc.
> >
> > This paves the way for some upcoming allocator improvements
> >
> > BUG=3Dnone
> > TEST=3Dnone
> >
> >
> > Please review this at http://codereview.chromium.org/199041
> >
> > SVN Base: svn://chrome-svn/chrome/trunk/src/
> >
> > Affected files:
> > =A0M =A0 =A0 chrome/chrome.gyp
> >
> >
> >

[Anton Muhin, 2009-09-07 19:16:33]

Oh, not quite---it was not only about new operator.  Debug builds of
many unit tests are linked against LIBCMTD.lib.  But tcmalloc.lib
brings LIBCMT.lib, now we've got conflicts.  I solved it propagate
ignoring LIBCMTD in libraries dependent on tcmalloc.lib (for some
reason direct_dependency_settings didn't work for me).  Please, take a
look at http://codereview.chromium.org/172109/

yours,
anton.

On Mon, Sep 7, 2009 at 11:08 PM, <mbelshe@chromium.org> wrote:
> Right - this change is dependent on
>
> http://codereview.chromium.org/200036
>
> to fix the problem you mention for debug builds.
>
> Mike
>
>
> On 2009/09/07 17:19:07, antonm_google.com wrote:
>>
>> LGTM, but that didn't compile that way for me: the problem was with
>> conflicting definitions coming from LIBCMTD. =A0I had to inject several
>> export_dependent_settings (for some reason declare_dependency_setting
>> didn't work).
>
>> yours,
>> anton.
>
>> On Mon, Sep 7, 2009 at 9:07 PM, <mailto:mbelshe@chromium.org> wrote:
>> > Reviewers: sgk,
>> >
>> > Message:
>> > We're going to add some hooks for the renderer to use some
>
> additional
>>
>> > allocator functionality; as such, anything that links the renderer
>
> needs
>>
>> > to use tcmalloc.
>> >
>> > I'm going to do a test checkin today (while its a holiday) to see
>
> how
>>
>> > the tests hold up. =3DA0I'll back out.
>> >
>> > Description:
>> > Make ui_tests (and any renderer-based PE) use tcmalloc.
>> >
>> > This paves the way for some upcoming allocator improvements
>> >
>> > BUG=3D3Dnone
>> > TEST=3D3Dnone
>> >
>> >
>> > Please review this at http://codereview.chromium.org/199041
>> >
>> > SVN Base: svn://chrome-svn/chrome/trunk/src/
>> >
>> > Affected files:
>> > =3DA0M =3DA0 =3DA0 chrome/chrome.gyp
>> >
>> >
>> >
>
>
>
> http://codereview.chromium.org/199041
>

[TVL, 2009-09-08 01:12:02]

Looks like this is causing compile failures on the purify bot:
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/bu...

[mbelshe, 2009-09-08 05:43:19]

Looks like you are right.
I don't know why that didn't show up earlier.  Maybe it just took forever to
run.

I know the cause and will fix.

Mike


On Mon, Sep 7, 2009 at 6:11 PM, <thomasvl@chromium.org> wrote:

> Looks like this is causing compile failures on the purify bot:
>
>
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/bu...
>
>
> http://codereview.chromium.org/199041
>

[mbelshe, 2009-09-08 05:44:07]

Looks like you are right.
I don't know why that didn't show up earlier.  Maybe it just took forever to
run.

I know the cause and will fix.

Mike


On Mon, Sep 7, 2009 at 6:11 PM, <thomasvl@chromium.org> wrote:

> Looks like this is causing compile failures on the purify bot:
>
>
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/bu...
>
>
> http://codereview.chromium.org/199041
>

[TVL, 2009-09-08 12:19:30]

On Tue, Sep 8, 2009 at 1:39 AM, Mike Belshe <mbelshe@google.com> wrote:

> Looks like you are right.
> I don't know why that didn't show up earlier.  Maybe it just took forever
> to run.
>
> I know the cause and will fix.
>

Thanks!

TVL


>
> Mike
>
>
> On Mon, Sep 7, 2009 at 6:11 PM, <thomasvl@chromium.org> wrote:
>
>> Looks like this is causing compile failures on the purify bot:
>>
>>
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/bu...
>>
>>
>> http://codereview.chromium.org/199041
>>
>
>

[sgk, 2009-09-08 15:50:14]

Scattering explicit conditional links in each of the separate executables seems
sub-optimal.  Would it make sense to parameterize this behind a <(malloc)
variable so hypothetically switching to another malloc library in the future
doesn't require making all of the by-hand changes?

Otherwise, code itself lgtm.