c++11 ud suffix fixes for tcmalloc files

c++11 ud suffix fixes for tcmalloc files

No behavior change.

BUG=263960
R=willchan@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=214256

[willchan no longer on Chromium, 2013-07-29 22:16:11]

Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be busy, so
maybe he can look before I next get a chance to.

It looks like the majority of these are in the code from upstream
google-perftools. Can we fix upstream and downintegrate?

If this is blocking something and it's more convenient to fix it here instead,
then I'm happy to approve a change here instead.

[Nico, 2013-07-29 22:18:10]

On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:

> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
> busy, so
> maybe he can look before I next get a chance to.
>

It's just adding a few spaces.


> It looks like the majority of these are in the code from upstream
> google-perftools. Can we fix upstream and downintegrate?
>

Sure, do you have examples of where we've done that before?


>
> If this is blocking something and it's more convenient to fix it here
> instead,
> then I'm happy to approve a change here instead.
>
>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>

[Nico, 2013-07-29 22:19:57]

On Mon, Jul 29, 2013 at 3:18 PM, Nico Weber <thakis@chromium.org> wrote:

> On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:
>
>> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
>> busy, so
>> maybe he can look before I next get a chance to.
>>
>
> It's just adding a few spaces.
>
>
>> It looks like the majority of these are in the code from upstream
>> google-perftools. Can we fix upstream and downintegrate?
>>
>
> Sure, do you have examples of where we've done that before?
>

(For example, it wasn't done for the Android changes as far as I can tell.)


>
>
>>
>> If this is blocking something and it's more convenient to fix it here
>> instead,
>> then I'm happy to approve a change here instead.
>>
>>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>>
>
>

[willchan no longer on Chromium, 2013-07-29 22:25:54]

On Mon, Jul 29, 2013 at 3:18 PM, Nico Weber <thakis@chromium.org> wrote:

> On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:
>
>> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
>> busy, so
>> maybe he can look before I next get a chance to.
>>
>
> It's just adding a few spaces.
>

Sure. I'm fine with doing it here first if this is blocking something like
enabling a new C++11 bot or something. But otherwise, I'd like us to make
changes upstream and downintegrate where possible.


>
>
>> It looks like the majority of these are in the code from upstream
>> google-perftools. Can we fix upstream and downintegrate?
>>
>
> Sure, do you have examples of where we've done that before?
>

http://git.chromium.org/gitweb/?p=chromium/src.git;a=commit;h=d2a95102b1c4607...


>
>>
>> If this is blocking something and it's more convenient to fix it here
>> instead,
>> then I'm happy to approve a change here instead.
>>
>>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>>
>
>

[willchan no longer on Chromium, 2013-07-29 22:29:52]

IIRC that's just another example of us letting in changes sooner in order
to unblock certain efforts like getting DMP on Android and upstream
afterward. Technical debt tradeoff. I think we should try to do a better
job here when possible.

I'm also conscious of not wanting to send you off to shave a herd of yaks
if the downintegration turns out to have picked up a bunch of other stuff
that would cause issues. Let me look at this CL now (my plane got delayed,
I'm stuck here, bah humbug) and probably approve it so you can commit in
case upstream changes and the downintegrate are unreasonably complicated.


On Mon, Jul 29, 2013 at 3:19 PM, Nico Weber <thakis@chromium.org> wrote:

> On Mon, Jul 29, 2013 at 3:18 PM, Nico Weber <thakis@chromium.org> wrote:
>
>> On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:
>>
>>> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
>>> busy, so
>>> maybe he can look before I next get a chance to.
>>>
>>
>> It's just adding a few spaces.
>>
>>
>>> It looks like the majority of these are in the code from upstream
>>> google-perftools. Can we fix upstream and downintegrate?
>>>
>>
>> Sure, do you have examples of where we've done that before?
>>
>
> (For example, it wasn't done for the Android changes as far as I can tell.)
>
>
>>
>>
>>>
>>> If this is blocking something and it's more convenient to fix it here
>>> instead,
>>> then I'm happy to approve a change here instead.
>>>
>>>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>>>
>>
>>
>

[Nico, 2013-07-29 22:30:05]

On Mon, Jul 29, 2013 at 3:25 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> On Mon, Jul 29, 2013 at 3:18 PM, Nico Weber <thakis@chromium.org> wrote:
>
>> On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:
>>
>>> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
>>> busy, so
>>> maybe he can look before I next get a chance to.
>>>
>>
>> It's just adding a few spaces.
>>
>
> Sure. I'm fine with doing it here first if this is blocking something like
> enabling a new C++11 bot or something.
>

This isn't blocking anything.


> But otherwise, I'd like us to make changes upstream and downintegrate
> where possible.
>
>
>>
>>
>>> It looks like the majority of these are in the code from upstream
>>> google-perftools. Can we fix upstream and downintegrate?
>>>
>>
>> Sure, do you have examples of where we've done that before?
>>
>
>
>
http://git.chromium.org/gitweb/?p=chromium/src.git;a=commit;h=d2a95102b1c4607...
>

So I'm on the hook for manually integrating a new tcmalloc after landing my
changes upstream? That doesn't look like a reasonable model to me. This
commit updated us to r144, gperftools head is at r232. I'm not familiar
with tcmalloc code, so I'm not in a good position to pull in close to 90
new revisions.

I'm happy to make sure this (and another downstream change I made in the
past) are also pushed to upstream, but landing upstream and then rolling
tcmalloc to upstream trunk doesn't sound good to me.


>
>
>
>>
>>>
>>> If this is blocking something and it's more convenient to fix it here
>>> instead,
>>> then I'm happy to approve a change here instead.
>>>
>>>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>>>
>>
>>
>

[willchan no longer on Chromium, 2013-07-29 22:33:11]

These fixes LGTM

[Nico, 2013-07-29 22:35:57]

On Mon, Jul 29, 2013 at 3:33 PM, <willchan@chromium.org> wrote:

> These fixes LGTM
>

Thanks!


>
>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>

[willchan no longer on Chromium, 2013-07-29 22:35:57]

On Mon, Jul 29, 2013 at 3:30 PM, Nico Weber <thakis@chromium.org> wrote:

> On Mon, Jul 29, 2013 at 3:25 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> On Mon, Jul 29, 2013 at 3:18 PM, Nico Weber <thakis@chromium.org> wrote:
>>
>>> On Mon, Jul 29, 2013 at 3:16 PM, <willchan@chromium.org> wrote:
>>>
>>>> Adding jar@ since I'm traveling to Berlin for IETF 87 and expect to be
>>>> busy, so
>>>> maybe he can look before I next get a chance to.
>>>>
>>>
>>> It's just adding a few spaces.
>>>
>>
>> Sure. I'm fine with doing it here first if this is blocking something
>> like enabling a new C++11 bot or something.
>>
>
> This isn't blocking anything.
>
>
>>  But otherwise, I'd like us to make changes upstream and downintegrate
>> where possible.
>>
>>
>>>
>>>
>>>> It looks like the majority of these are in the code from upstream
>>>> google-perftools. Can we fix upstream and downintegrate?
>>>>
>>>
>>> Sure, do you have examples of where we've done that before?
>>>
>>
>>
>>
http://git.chromium.org/gitweb/?p=chromium/src.git;a=commit;h=d2a95102b1c4607...
>>
>
> So I'm on the hook for manually integrating a new tcmalloc after landing
> my changes upstream? That doesn't look like a reasonable model to me. This
> commit updated us to r144, gperftools head is at r232. I'm not familiar
> with tcmalloc code, so I'm not in a good position to pull in close to 90
> new revisions.
>

I'm surprised gperftools is changing so rapidly. I agree it's unreasonable
to ask you to roll so many revisions. I made that request without the
knowledge that so much had changed.


>
> I'm happy to make sure this (and another downstream change I made in the
> past) are also pushed to upstream, but landing upstream and then rolling
> tcmalloc to upstream trunk doesn't sound good to me.
>

Yeah, it'd be great if you can just make the changes upstream and leave the
rolling up to us. Clearly we should be doing a better job of actively
maintaining this code =/


>
>
>>
>>
>>
>>>
>>>>
>>>> If this is blocking something and it's more convenient to fix it here
>>>> instead,
>>>> then I'm happy to approve a change here instead.
>>>>
>>>>
https://codereview.chromium.**org/21157004/<https://codereview.chromium.org/2...
>>>>
>>>
>>>
>>
>

[Nico, 2013-07-29 23:31:01]

Committed patchset #1 manually as r214256 (presubmit successful).