<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>In summary, shortest:<div><br></div><div><br></div><div> We must be able to read registers (or save them to the stack or elsewhere (known thread locals)). </div><div> We must be able to read the stack. </div><div> We need not write registers or stack (from garbage collector). </div><div><br></div><div><br></div><div>Slight elaboration:</div><div> Copying/compaction only occurs when references are only from globals and heap. </div><div> Therefore updates/writes only occur to globals and heap. </div><div><br></div><div><br></div><div> Is there any desire to do better/different? </div><div> To require the ability to update stack/registers? </div><div> What does Java typically to? </div><div><br></div><div><br></div><div><br></div><div>I guess there is the problem that we don't know for certain if values in registers and stack are pointers, or just coincident integers, and so updating them can be wrong.</div><div>Whereas in the globals and "reachable thereof" we have precise type information for, so we can update those values safely.</div><div>To do better/different would require more backend cooperation.</div><div><span style="font-size: 12pt;">We conservatively treat registers/stack as pointers if they look like them, and therefore keep values alive, but not trust them so much as to update them.</span></div><div><br></div><div><br></div><div>Thanks,</div><div> - Jay<br><br><div><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Fri, 24 Jan 2014 13:12:33 -0500<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] garbage collector compacting and volatile?<br><br>On Jan 24, 2014, at 5:38 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><div><br class="ecxApple-interchange-newline"><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr">Is our garbage collector compacting?<br></div></div></blockquote><div><br></div><div>Yes, it is mostly-copying.</div><div>Only pages that are not referred to from the stack (i.e., only from other objects) have their objects relocated (compacted).</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">In particular, what model do we need for "volatile" in codegen?</span><br>Does the compactor read the registers or just the stack?<br></div></div></blockquote><div><br></div><div>It reads both registers and stack.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr">Update references anywhere? Just the stack? Also context?<br></div></div></blockquote><div><br></div><div>The collector first pins all pages referenced from the stacks, including registers.</div><div>Any page not pinned has its reachable objects evacuated and all references to those objects (i.e., from other objects) are updated to refer to the the new location.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">There are tradeoffs either way.</span><br></div></div></blockquote><div><br></div><div>Indeed. Too many to enumerate here.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">If it is not compacting and only reads the stack, then it can be more</span><br>portable, but every write of a collected type/pointer would have to be volatile.<br>Or is that what the barriers are for?<br></div></div></blockquote><div><br></div><div>The write barrier allows the collector to run concurrently with the mutator (once all stack roots have been sampled).</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">If we update values on the stack, then there is some portability,</span><br>but reads and writes would have to be volatile.<br></div></div></blockquote><div><br></div><div>No updates to values on the stacks.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">If we read and write registers in the collector, then nothing has to be volatile.</span><br></div></div></blockquote><div><br></div><div>Read only. No writes to registers.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">Should this all be parameters passed to the backend?</span><br></div></div></blockquote><div><br></div><div>Nope.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr">And/or preserved via #ifdef in the C backend?<br>That last part is easy enough, for generated C to take #ifdefs<br>indicating if reads and/or writes should be volatile.<br></div></div></blockquote><div><br></div><div>Nope.</div><br><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div dir="ltr"><span style="font-size:12pt;">If the collector is not compacting, then it need not update</span><br>stack or register values, just possibly read them.<br><br>I recall reading that it is compacting.<br></div></div></blockquote></div><div><br></div><div>It is mostly-copying.</div><div><br></div></div></div> </div></body>
</html>