Save 166 KB of per-process private data by deleting 'const'

Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
Committed: https://crrev.com/7a0168cc2fae634b15e720527bfcd2d75ff21def
Cr-Commit-Position: refs/heads/master@{#441211}

[brucedawson, 2016-12-29 00:35:52]

The CQ bit was checked by brucedawson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-29 00:35:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-29 01:23:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-29 01:23:42]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2016-12-29 04:11:15]

Description was changed from

==========
Save 224 KB of code by deleting 'const' three times

VC++ has an odd bug where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, the compiler seems to generate code to do the
initialization, even in full official builds.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for chrome.dll on a release non-official build are shown below - the
savings for chrome_child.dll are almost exactly the same.

chrome.dll
       .text: -111808 bytes change
      .rdata:  166992 bytes change
       .data: -166240 bytes change
      .reloc:  -22924 bytes change
Total change: -133980 bytes

Having data in the .rdata section is strictly better because it is
guaranteed to be sharable between processes, and it cannot be corrupted
by stray writes. The code-size improvements are an unexpected bonus.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

to

==========
Save 224 KB of code by deleting 'const' three times

VC++ has an odd bug where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, the compiler seems to generate code to do the
initialization, even in full official builds.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math or logic behind this change.

Having data in the .rdata section is strictly better because it is
guaranteed to be sharable between processes, and it cannot be corrupted
by stray writes. The code-size improvements are an unexpected bonus.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

[brucedawson, 2016-12-29 04:11:16]

brucedawson@chromium.org changed reviewers:
+ rockot@chromium.org

[brucedawson, 2016-12-29 04:11:49]

Strange, but effective. Part one of several. PTAL.

[brucedawson, 2016-12-29 19:18:37]

Description was changed from

==========
Save 224 KB of code by deleting 'const' three times

VC++ has an odd bug where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, the compiler seems to generate code to do the
initialization, even in full official builds.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math or logic behind this change.

Having data in the .rdata section is strictly better because it is
guaranteed to be sharable between processes, and it cannot be corrupted
by stray writes. The code-size improvements are an unexpected bonus.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

to

==========
Save 224 KB of code by deleting 'const' three times

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, the compiler seems to generate code to do the
initialization, even in full official builds.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

Having data in the .rdata section is strictly better because it is
guaranteed to be sharable between processes, and it cannot be corrupted
by stray writes. The code-size improvements are an unexpected bonus.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

[brucedawson, 2017-01-03 19:50:29]

Description was changed from

==========
Save 224 KB of code by deleting 'const' three times

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, the compiler seems to generate code to do the
initialization, even in full official builds.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

Having data in the .rdata section is strictly better because it is
guaranteed to be sharable between processes, and it cannot be corrupted
by stray writes. The code-size improvements are an unexpected bonus.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

to

==========
Save 332 KB of per-process private data by deleting 'const'

Also saves 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

[brucedawson, 2017-01-03 19:57:20]

Description was changed from

==========
Save 332 KB of per-process private data by deleting 'const'

Also saves 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

to

==========
Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

[Ken Rockot(use gerrit already), 2017-01-03 20:09:24]

lgtm

[brucedawson, 2017-01-03 20:26:53]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2017-01-03 20:27:15]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-03 21:26:58]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1483475213226850, "parent_rev":
"df2ab937041ed6320c0e17fba1eae715f4857837", "commit_rev":
"ec319476abc11398ae5c13b12684964f145e8454"}

[commit-bot: I haz the power, 2017-01-03 21:27:23]

Description was changed from

==========
Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351
==========

to

==========
Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351

Review-Url: https://codereview.chromium.org/2607893002
==========

[commit-bot: I haz the power, 2017-01-03 21:27:26]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2017-01-03 21:31:48]

Description was changed from

==========
Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351

Review-Url: https://codereview.chromium.org/2607893002
==========

to

==========
Save 166 KB of per-process private data by deleting 'const'

Also saves a total of 224 KB of code.

VC++ has an odd quirk where if you have a const array of structs where the
structs have some const members then the compiler stores the array in
the .data (read/write section) instead of the .rdata (read-only
section). Worse yet, in this case the compiler generates code to do the
initialization, even in full official builds. This wastes code/reloc
space and also means that the arrays all turn into per-process private
data. That is, every Chrome process was ending up with a private copy of
the many global arrays which this change fixes.

This anomaly was discovered while investigating why a couple of large
const arrays were in the wrong section. The section size improvements
for full official build are shown below:

chrome.dll
       .text: -111744 bytes change
      .rdata:  165824 bytes change
       .data: -166208 bytes change
      .reloc:  -23864 bytes change
Total change: -135992 bytes

chrome_child.dll
       .text: -111904 bytes change
      .rdata:  166000 bytes change
       .data: -166240 bytes change
      .reloc:  -23832 bytes change
Total change: -135976 bytes

The on-disk size of each binary shrinks by 88,576 bytes. I do not
understand any of the math behind how section sizes map to binary sizes.

The VC++ tracking bug is:
https://connect.microsoft.com/VisualStudio/feedback/details/3117602

BUG=677351

Committed: https://crrev.com/7a0168cc2fae634b15e720527bfcd2d75ff21def
Cr-Commit-Position: refs/heads/master@{#441211}
==========

[commit-bot: I haz the power, 2017-01-03 21:31:49]

Patchset 1 (id:??) landed as
https://crrev.com/7a0168cc2fae634b15e720527bfcd2d75ff21def
Cr-Commit-Position: refs/heads/master@{#441211}

[brucedawson, 2017-01-04 17:48:27]

On 2017/01/03 21:31:49, commit-bot: I haz the power wrote:
> Patchset 1 (id:??) landed as
> https://crrev.com/7a0168cc2fae634b15e720527bfcd2d75ff21def
> Cr-Commit-Position: refs/heads/master@{#441211}

I just looked in more detail at the before/after count of global variables in
the read/write data segment, from yesterday's canary build to today's. This
change caused 1,501 global variables, totaling about 167,000 bytes, to move to
the read-only segment. This matches the previously surprising change in the size
of the .data segment which I had measured but not fully understood because I was
only looking at large globals, and some of the affected globals are as small as
eight bytes.