<div dir="ltr">On Tue, Feb 18, 2014 at 2:42 PM, Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">For scaling, the next step would be to swap out to disk - if that happens as a hibernate to disk, all the other functionality would stick around (as opposed to an application level write-state-to-disk).  Hence the question re. internals of the hibernate BIF and the scheduler, and how one might think about wiring in a hibernate-to-disk function.<br>
</div>
<br></blockquote><div><br></div><div>If I were to do something like this I would first try to only put the heap and referenced off heap binaries to disk. This should be the majority of the memory footprint and will allow all process meta data (links, monitors, registry etc etc) to remain unaffected. The question is what to do about the stack which could contain pointers to code that has been changed while the process was hibernated. </div>
<div><br></div><div>Lukas</div></div></div></div>