tcmalloc: Let DEFINE_string define char arrays.

tcmalloc: Let DEFINE_string define const char*s.

DEFINE_string is used in 3 files in tcmalloc, but we only compile one of
these.  In this one file, the string is converted to char every time it's used,
and since the string is used after global destructors have run it needs to be
copied to a second string in a static initializer.

Instead of all that silliness, just let DEFINE_string define a const char*
(like it does in v8 or webrtc).

BUG=94925
R=willchan@chromium.org

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

[willchan no longer on Chromium, 2014-05-18 15:42:37]

lgtm

[Nico, 2014-05-18 19:03:10]

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

[Evan Martin, 2014-05-19 20:55:08]

Possible to take upstream?

[Nico, 2014-05-19 20:58:44]

On 2014/05/19 20:55:08, Evan Martin wrote:
> Possible to take upstream?

Probably, the other two files that call this are easy to change too. (But they
would have to be changed for upstreaming.)

I'm pretty confused about the tcmalloc upstreaming relationship though: From
what I can tell, tcmalloc was open-sourced at some point, and then developed
independently internally and externally, and chromium seems to track neither of
these upstreams :-/

[willchan no longer on Chromium, 2014-05-19 21:07:31]

These patches aren't appropriate for upstreaming due to the reliance on the
PROFILING macro definition set by the gyp flag, which upstream has no
concept of. Indeed, the typical usage is to always bake in profiling.

TCMalloc was open sourced and development continued internally. In
Chromium, we forked the open source one and put a half hearted effort to
upstream patches. I've been notifying the google-perftools maintainer of
the ones which I consider acceptable for upstreaming. I haven't enforced
checking in upstream first because we're so far behind upstream now. It'd
be 1-3 engineer-days to catch up. We should probably do this at some point
but we never get around to it.


On Mon, May 19, 2014 at 1:58 PM, <thakis@chromium.org> wrote:

> On 2014/05/19 20:55:08, Evan Martin wrote:
>
>> Possible to take upstream?
>>
>
> Probably, the other two files that call this are easy to change too. (But
> they
> would have to be changed for upstreaming.)
>
> I'm pretty confused about the tcmalloc upstreaming relationship though:
> From
> what I can tell, tcmalloc was open-sourced at some point, and then
> developed
> independently internally and externally, and chromium seems to track
> neither of
> these upstreams :-/
>
> https://codereview.chromium.org/286953011/
>

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

[Nico, 2014-05-19 21:08:19]

On Mon, May 19, 2014 at 2:07 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> These patches aren't appropriate for upstreaming due to the reliance on
> the PROFILING macro definition set by the gyp flag, which upstream has no
> concept of. Indeed, the typical usage is to always bake in profiling.
>

This patch doesn't rely on PROFILING (the others did).


> TCMalloc was open sourced and development continued internally. In
> Chromium, we forked the open source one and put a half hearted effort to
> upstream patches. I've been notifying the google-perftools maintainer of
> the ones which I consider acceptable for upstreaming. I haven't enforced
> checking in upstream first because we're so far behind upstream now. It'd
> be 1-3 engineer-days to catch up. We should probably do this at some point
> but we never get around to it.
>
>
> On Mon, May 19, 2014 at 1:58 PM, <thakis@chromium.org> wrote:
>
>> On 2014/05/19 20:55:08, Evan Martin wrote:
>>
>>> Possible to take upstream?
>>>
>>
>> Probably, the other two files that call this are easy to change too. (But
>> they
>> would have to be changed for upstreaming.)
>>
>> I'm pretty confused about the tcmalloc upstreaming relationship though:
>> From
>> what I can tell, tcmalloc was open-sourced at some point, and then
>> developed
>> independently internally and externally, and chromium seems to track
>> neither of
>> these upstreams :-/
>>
>> https://codereview.chromium.org/286953011/
>>
>
>

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

[willchan no longer on Chromium, 2014-05-19 21:09:59]

My bad, I'm getting senile :)


On Mon, May 19, 2014 at 2:08 PM, Nico Weber <thakis@chromium.org> wrote:

> On Mon, May 19, 2014 at 2:07 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> These patches aren't appropriate for upstreaming due to the reliance on
>> the PROFILING macro definition set by the gyp flag, which upstream has no
>> concept of. Indeed, the typical usage is to always bake in profiling.
>>
>
> This patch doesn't rely on PROFILING (the others did).
>
>
>> TCMalloc was open sourced and development continued internally. In
>> Chromium, we forked the open source one and put a half hearted effort to
>> upstream patches. I've been notifying the google-perftools maintainer of
>> the ones which I consider acceptable for upstreaming. I haven't enforced
>> checking in upstream first because we're so far behind upstream now. It'd
>> be 1-3 engineer-days to catch up. We should probably do this at some point
>> but we never get around to it.
>>
>>
>> On Mon, May 19, 2014 at 1:58 PM, <thakis@chromium.org> wrote:
>>
>>> On 2014/05/19 20:55:08, Evan Martin wrote:
>>>
>>>> Possible to take upstream?
>>>>
>>>
>>> Probably, the other two files that call this are easy to change too.
>>> (But they
>>> would have to be changed for upstreaming.)
>>>
>>> I'm pretty confused about the tcmalloc upstreaming relationship though:
>>> From
>>> what I can tell, tcmalloc was open-sourced at some point, and then
>>> developed
>>> independently internally and externally, and chromium seems to track
>>> neither of
>>> these upstreams :-/
>>>
>>> https://codereview.chromium.org/286953011/
>>>
>>
>>
>

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