<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>212878</bug_id>
          
          <creation_ts>2020-06-07 02:05:48 -0700</creation_ts>
          <short_desc>Lazily allocate HistoricUsageData</short_desc>
          <delta_ts>2021-12-19 13:11:52 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>New Bugs</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          <see_also>https://bugs.webkit.org/show_bug.cgi?id=233476</see_also>
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Yusuke Suzuki">ysuzuki</reporter>
          <assigned_to name="Yusuke Suzuki">ysuzuki</assigned_to>
          <cc>saam</cc>
    
    <cc>sam</cc>
    
    <cc>simon.fraser</cc>
    
    <cc>webkit-bug-importer</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1660045</commentid>
    <comment_count>0</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2020-06-07 02:05:48 -0700</bug_when>
    <thetext>Lazily allocate HistoricUsageData</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660046</commentid>
    <comment_count>1</comment_count>
      <attachid>401289</attachid>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2020-06-07 02:06:23 -0700</bug_when>
    <thetext>Created attachment 401289
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660047</commentid>
    <comment_count>2</comment_count>
      <attachid>401290</attachid>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2020-06-07 02:07:32 -0700</bug_when>
    <thetext>Created attachment 401290
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660078</commentid>
    <comment_count>3</comment_count>
    <who name="Sam Weinig">sam</who>
    <bug_when>2020-06-07 08:21:41 -0700</bug_when>
    <thetext>Hey Yusuke, just so I understand a little better, what is the benefit of removing this from the __DATA section?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660322</commentid>
    <comment_count>4</comment_count>
    <who name="Saam Barati">saam</who>
    <bug_when>2020-06-08 12:58:10 -0700</bug_when>
    <thetext>(In reply to Sam Weinig from comment #3)
&gt; Hey Yusuke, just so I understand a little better, what is the benefit of
&gt; removing this from the __DATA section?

I believe the goal is to reduce dirty memory usage</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660323</commentid>
    <comment_count>5</comment_count>
    <who name="Saam Barati">saam</who>
    <bug_when>2020-06-08 12:59:40 -0700</bug_when>
    <thetext>(In reply to Saam Barati from comment #4)
&gt; (In reply to Sam Weinig from comment #3)
&gt; &gt; Hey Yusuke, just so I understand a little better, what is the benefit of
&gt; &gt; removing this from the __DATA section?
&gt; 
&gt; I believe the goal is to reduce dirty memory usage

I guess to elaborate on how I model my understanding:
This will take away space from other things in DATA that could’ve theoretically fit on one page and perhaps bumping it into two.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660326</commentid>
    <comment_count>6</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2020-06-08 13:02:45 -0700</bug_when>
    <thetext>(In reply to Saam Barati from comment #5)
&gt; (In reply to Saam Barati from comment #4)
&gt; &gt; (In reply to Sam Weinig from comment #3)
&gt; &gt; &gt; Hey Yusuke, just so I understand a little better, what is the benefit of
&gt; &gt; &gt; removing this from the __DATA section?
&gt; &gt; 
&gt; &gt; I believe the goal is to reduce dirty memory usage
&gt; 
&gt; I guess to elaborate on how I model my understanding:
&gt; This will take away space from other things in DATA that could’ve
&gt; theoretically fit on one page and perhaps bumping it into two.

Yes, since __DATA is per page, it is possible that we construct a page like,


[&lt;---------------------------historicUsageData-------------&gt;&lt;-small data-&gt;]

In that case, if small data gets dirty, it taints entire page dirty even if historicUsageData part is not used at all.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1660346</commentid>
    <comment_count>7</comment_count>
    <who name="Sam Weinig">sam</who>
    <bug_when>2020-06-08 13:18:28 -0700</bug_when>
    <thetext>(In reply to Yusuke Suzuki from comment #6)
&gt; (In reply to Saam Barati from comment #5)
&gt; &gt; (In reply to Saam Barati from comment #4)
&gt; &gt; &gt; (In reply to Sam Weinig from comment #3)
&gt; &gt; &gt; &gt; Hey Yusuke, just so I understand a little better, what is the benefit of
&gt; &gt; &gt; &gt; removing this from the __DATA section?
&gt; &gt; &gt; 
&gt; &gt; &gt; I believe the goal is to reduce dirty memory usage
&gt; &gt; 
&gt; &gt; I guess to elaborate on how I model my understanding:
&gt; &gt; This will take away space from other things in DATA that could’ve
&gt; &gt; theoretically fit on one page and perhaps bumping it into two.
&gt; 
&gt; Yes, since __DATA is per page, it is possible that we construct a page like,
&gt; 
&gt; 
&gt; [&lt;---------------------------historicUsageData-------------&gt;&lt;-small data-&gt;]
&gt; 
&gt; In that case, if small data gets dirty, it taints entire page dirty even if
&gt; historicUsageData part is not used at all.

Interesting. Would it ever make sense to annotate these rarely used large data portions with a specific section name to allow the linker to group rarely used data together?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825429</commentid>
    <comment_count>8</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2021-12-19 01:35:44 -0800</bug_when>
    <thetext>(In reply to Sam Weinig from comment #7)
&gt; (In reply to Yusuke Suzuki from comment #6)
&gt; &gt; (In reply to Saam Barati from comment #5)
&gt; &gt; &gt; (In reply to Saam Barati from comment #4)
&gt; &gt; &gt; &gt; (In reply to Sam Weinig from comment #3)
&gt; &gt; &gt; &gt; &gt; Hey Yusuke, just so I understand a little better, what is the benefit of
&gt; &gt; &gt; &gt; &gt; removing this from the __DATA section?
&gt; &gt; &gt; &gt; 
&gt; &gt; &gt; &gt; I believe the goal is to reduce dirty memory usage
&gt; &gt; &gt; 
&gt; &gt; &gt; I guess to elaborate on how I model my understanding:
&gt; &gt; &gt; This will take away space from other things in DATA that could’ve
&gt; &gt; &gt; theoretically fit on one page and perhaps bumping it into two.
&gt; &gt; 
&gt; &gt; Yes, since __DATA is per page, it is possible that we construct a page like,
&gt; &gt; 
&gt; &gt; 
&gt; &gt; [&lt;---------------------------historicUsageData-------------&gt;&lt;-small data-&gt;]
&gt; &gt; 
&gt; &gt; In that case, if small data gets dirty, it taints entire page dirty even if
&gt; &gt; historicUsageData part is not used at all.
&gt; 
&gt; Interesting. Would it ever make sense to annotate these rarely used large
&gt; data portions with a specific section name to allow the linker to group
&gt; rarely used data together?

It is nice! So, if it is the data we need definitely, we should do that. But at the same time, by doing heap-allocation here, this patch reduces binary size :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825430</commentid>
    <comment_count>9</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2021-12-19 01:41:03 -0800</bug_when>
    <thetext>Committed r287238 (245398@trunk): &lt;https://commits.webkit.org/245398@trunk&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825431</commentid>
    <comment_count>10</comment_count>
    <who name="Radar WebKit Bug Importer">webkit-bug-importer</who>
    <bug_when>2021-12-19 01:42:19 -0800</bug_when>
    <thetext>&lt;rdar://problem/86680604&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825446</commentid>
    <comment_count>11</comment_count>
    <who name="Simon Fraser (smfr)">simon.fraser</who>
    <bug_when>2021-12-19 09:31:31 -0800</bug_when>
    <thetext>Funny, I did this same thing but found that it didn&apos;t change binary size.

The __DATA/_bss section is constructed at runtime (fresh pages mapped into memory). But if it has the side effect of shuffling around other things in __DATA then maybe it can affect binary size?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825448</commentid>
    <comment_count>12</comment_count>
    <who name="Simon Fraser (smfr)">simon.fraser</who>
    <bug_when>2021-12-19 09:33:30 -0800</bug_when>
    <thetext>See bug 233476.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1825476</commentid>
    <comment_count>13</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2021-12-19 13:11:52 -0800</bug_when>
    <thetext>(In reply to Simon Fraser (smfr) from comment #11)
&gt; Funny, I did this same thing but found that it didn&apos;t change binary size.
&gt; 
&gt; The __DATA/_bss section is constructed at runtime (fresh pages mapped into
&gt; memory). But if it has the side effect of shuffling around other things in
&gt; __DATA then maybe it can affect binary size?

Ah! Yes. But anyway, the original intent of this patch is avoid having dirty __DATA memory by purging large rarely used data from __DATA (as described in https://bugs.webkit.org/show_bug.cgi?id=212878#c6), and it is still held :)</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>401289</attachid>
            <date>2020-06-07 02:06:23 -0700</date>
            <delta_ts>2020-06-07 02:07:31 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-212878-20200607020622.patch</filename>
            <type>text/plain</type>
            <size>1610</size>
            <attacher name="Yusuke Suzuki">ysuzuki</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjYyNjk0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D
aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNjQxMjczMjAyMmI0N2Fh
NGY2MTBhZWY2Y2I3M2U3NzM3MTFlOTc0NS4uZDQ3OWQ4NThhMjU5ZDRmODgxMTNkNjc2MDkwMmY5
ZTc5ZWNmMjY5NiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv
dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDIwLTA2LTA3ICBZdXN1
a2UgU3V6dWtpICA8eXN1enVraUBhcHBsZS5jb20+CisKKyAgICAgICAgTGF6aWx5IGFsbG9jYXRl
IEhpc3RvcmljVXNhZ2VEYXRhCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df
YnVnLmNnaT9pZD0yMTI4NzgKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4K
KworICAgICAgICBUaGlzIGlzIG9ubHkgdXNlZCB3aGVuIHJlc291cmNlLW92ZXJsYXkgaXMgZW5h
YmxlZC4gV2Ugc2hvdWxkIGFsbG9jYXRlIGl0IGxhemlseSBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhp
cyBpbiBfX0RBVEEuCisKKyAgICAgICAgKiBwYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5
Q29jb2EubW06CisgICAgICAgIChXZWJDb3JlOjpoaXN0b3JpY1VzYWdlRGF0YSk6CisKIDIwMjAt
MDYtMDYgIFl1c3VrZSBTdXp1a2kgIDx5c3V6dWtpQGFwcGxlLmNvbT4KIAogICAgICAgICBDcmFz
aCB3aGVuIHJ1bm5pbmcgd2ViLWFwaXMgZGF0YSBjb2xsZWN0aW9uCmRpZmYgLS1naXQgYS9Tb3Vy
Y2UvV2ViQ29yZS9wYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5Q29jb2EubW0gYi9Tb3Vy
Y2UvV2ViQ29yZS9wYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5Q29jb2EubW0KaW5kZXgg
ZTI2MzkzNDZiYjY0YzZmNzk3NmFjOTc0Y2E4ZGZkOWZjMGNjNTAyYS4uNzMxNmQ5YTFhZDY4YWFl
MmQxM2MzZDg5MWZkMjNjNDhlYmE3ODUzYSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGFn
ZS9jb2NvYS9SZXNvdXJjZVVzYWdlT3ZlcmxheUNvY29hLm1tCisrKyBiL1NvdXJjZS9XZWJDb3Jl
L3BhZ2UvY29jb2EvUmVzb3VyY2VVc2FnZU92ZXJsYXlDb2NvYS5tbQpAQCAtMTg0LDggKzE4NCwx
MiBAQCBIaXN0b3JpY1Jlc291cmNlVXNhZ2VEYXRhOjpIaXN0b3JpY1Jlc291cmNlVXNhZ2VEYXRh
KCkKIAogc3RhdGljIEhpc3RvcmljUmVzb3VyY2VVc2FnZURhdGEmIGhpc3RvcmljVXNhZ2VEYXRh
KCkKIHsKLSAgICBzdGF0aWMgTmV2ZXJEZXN0cm95ZWQ8SGlzdG9yaWNSZXNvdXJjZVVzYWdlRGF0
YT4gZGF0YTsKLSAgICByZXR1cm4gZGF0YTsKKyAgICBzdGF0aWMgSGlzdG9yaWNSZXNvdXJjZVVz
YWdlRGF0YSogZGF0YSB7IG51bGxwdHIgfTsKKyAgICBzdGF0aWMgc3RkOjpvbmNlX2ZsYWcgb25j
ZUtleTsKKyAgICBzdGQ6OmNhbGxfb25jZShvbmNlS2V5LCBbJl0geworICAgICAgICBkYXRhID0g
bmV3IEhpc3RvcmljUmVzb3VyY2VVc2FnZURhdGE7CisgICAgfSk7CisgICAgcmV0dXJuICpkYXRh
OwogfQogCiBzdGF0aWMgdm9pZCBhcHBlbmREYXRhVG9IaXN0b3J5KGNvbnN0IFJlc291cmNlVXNh
Z2VEYXRhJiBkYXRhKQo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>401290</attachid>
            <date>2020-06-07 02:07:32 -0700</date>
            <delta_ts>2020-06-08 12:58:25 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-212878-20200607020731.patch</filename>
            <type>text/plain</type>
            <size>1809</size>
            <attacher name="Yusuke Suzuki">ysuzuki</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjYyNjk0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D
aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNjQxMjczMjAyMmI0N2Fh
NGY2MTBhZWY2Y2I3M2U3NzM3MTFlOTc0NS4uZDQ3OWQ4NThhMjU5ZDRmODgxMTNkNjc2MDkwMmY5
ZTc5ZWNmMjY5NiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv
dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDIwLTA2LTA3ICBZdXN1
a2UgU3V6dWtpICA8eXN1enVraUBhcHBsZS5jb20+CisKKyAgICAgICAgTGF6aWx5IGFsbG9jYXRl
IEhpc3RvcmljVXNhZ2VEYXRhCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df
YnVnLmNnaT9pZD0yMTI4NzgKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4K
KworICAgICAgICBUaGlzIGlzIG9ubHkgdXNlZCB3aGVuIHJlc291cmNlLW92ZXJsYXkgaXMgZW5h
YmxlZC4gV2Ugc2hvdWxkIGFsbG9jYXRlIGl0IGxhemlseSBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhp
cyBpbiBfX0RBVEEuCisKKyAgICAgICAgKiBwYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5
Q29jb2EubW06CisgICAgICAgIChXZWJDb3JlOjpoaXN0b3JpY1VzYWdlRGF0YSk6CisKIDIwMjAt
MDYtMDYgIFl1c3VrZSBTdXp1a2kgIDx5c3V6dWtpQGFwcGxlLmNvbT4KIAogICAgICAgICBDcmFz
aCB3aGVuIHJ1bm5pbmcgd2ViLWFwaXMgZGF0YSBjb2xsZWN0aW9uCmRpZmYgLS1naXQgYS9Tb3Vy
Y2UvV2ViQ29yZS9wYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5Q29jb2EubW0gYi9Tb3Vy
Y2UvV2ViQ29yZS9wYWdlL2NvY29hL1Jlc291cmNlVXNhZ2VPdmVybGF5Q29jb2EubW0KaW5kZXgg
ZTI2MzkzNDZiYjY0YzZmNzk3NmFjOTc0Y2E4ZGZkOWZjMGNjNTAyYS4uNTQyZTU5ODhlNzFjNzI1
NTk5MzIxM2QwZjJjNWJlNTc2Yzk0YTg1OSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGFn
ZS9jb2NvYS9SZXNvdXJjZVVzYWdlT3ZlcmxheUNvY29hLm1tCisrKyBiL1NvdXJjZS9XZWJDb3Jl
L3BhZ2UvY29jb2EvUmVzb3VyY2VVc2FnZU92ZXJsYXlDb2NvYS5tbQpAQCAtMTQ2LDYgKzE0Niw3
IEBAIHN0cnVjdCBIaXN0b3JpY01lbW9yeUNhdGVnb3J5SW5mbyB7CiB9OwogCiBzdHJ1Y3QgSGlz
dG9yaWNSZXNvdXJjZVVzYWdlRGF0YSB7CisgICAgV1RGX01BS0VfU1RSVUNUX0ZBU1RfQUxMT0NB
VEVEOwogICAgIEhpc3RvcmljUmVzb3VyY2VVc2FnZURhdGEoKTsKIAogICAgIFJpbmdCdWZmZXI8
ZmxvYXQ+IGNwdTsKQEAgLTE4NCw4ICsxODUsMTIgQEAgSGlzdG9yaWNSZXNvdXJjZVVzYWdlRGF0
YTo6SGlzdG9yaWNSZXNvdXJjZVVzYWdlRGF0YSgpCiAKIHN0YXRpYyBIaXN0b3JpY1Jlc291cmNl
VXNhZ2VEYXRhJiBoaXN0b3JpY1VzYWdlRGF0YSgpCiB7Ci0gICAgc3RhdGljIE5ldmVyRGVzdHJv
eWVkPEhpc3RvcmljUmVzb3VyY2VVc2FnZURhdGE+IGRhdGE7Ci0gICAgcmV0dXJuIGRhdGE7Cisg
ICAgc3RhdGljIEhpc3RvcmljUmVzb3VyY2VVc2FnZURhdGEqIGRhdGEgeyBudWxscHRyIH07Cisg
ICAgc3RhdGljIHN0ZDo6b25jZV9mbGFnIG9uY2VLZXk7CisgICAgc3RkOjpjYWxsX29uY2Uob25j
ZUtleSwgWyZdIHsKKyAgICAgICAgZGF0YSA9IG5ldyBIaXN0b3JpY1Jlc291cmNlVXNhZ2VEYXRh
OworICAgIH0pOworICAgIHJldHVybiAqZGF0YTsKIH0KIAogc3RhdGljIHZvaWQgYXBwZW5kRGF0
YVRvSGlzdG9yeShjb25zdCBSZXNvdXJjZVVzYWdlRGF0YSYgZGF0YSkK
</data>
<flag name="review"
          id="416695"
          type_id="1"
          status="+"
          setter="saam"
    />
          </attachment>
      

    </bug>

</bugzilla>