<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
 /* List Definitions */
 @list l0
        {mso-list-id:243297870;
        mso-list-type:hybrid;
        mso-list-template-ids:2090501588 -1129533406 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri","sans-serif";
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:"Times New Roman";}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=WordSection1>

<p class=MsoNormal>I have concerns about weak refs and weak maps, one concern
related to usability, one related to performance bugs, and another other
related to changing the complexity of the GC algorithm. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Usability<o:p></o:p></p>

<p class=MsoNormal>Weak maps act as a GC API and in doing so violate GC&#8217;s
greatest strength: &nbsp;the user does not have to be concerned with memory
management. &nbsp;Since the user can never observe that a key/value pair has
been deleted, &nbsp;weak maps are much better than weak refs but they still
seem capable of causing hard to diagnose and fix performance bugs related to memory
pressure and the particular GC implementation. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>GC implementation<o:p></o:p></p>

<p class=MsoNormal>Software stacks on multicores will need GCs to become
increasingly concurrent and latency free. Weak maps cause concurrent GCs and additional
mutator synchronizations. &nbsp;While a concurrent GC already has to do some
synchronization, each additional synchronization point impedes scalability. My
concern is that the number of synchronization points might be proportional to
the number of &lt;k, v&gt; pairs in the weak maps (see below).<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>GC Complexity<o:p></o:p></p>

<p class=MsoNormal>Another potential performance bug is that the complexity of
the Abstract GC Algorithm at <a
href="http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps">http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps</a>
appears to be O(n**2), since each loop may only discover a single retained key
k from (k,v) whose walk of the related value v discovers only a single unretained
k. This would then be repeated and require rescanning all the weak maps in the each
of the following iterations. Concurrent GCs would probable require one or more mutator
synchronizations at each iteration. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>My sense is that the value of a simple efficient concurrent
GC and reduced latency is higher than the value of weak maps so weak maps
should not be part of the standard.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Rick<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.25in'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='margin-left:.25in'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>