<div dir="ltr">Requires work, but not difficult work.<div><br></div><div>If you've implemented your own threads then presumably you can figure out how to stop them and plumb that into GC_stop_world() (or make the STOP_WORLD() macro call an entirely different function of your choice)</div><div><br></div><div>Similarly, if your stacks are not contiguous, you'll also know how to enumerate the various sections of them. Then it's only a matter of setting GC_push_other_roots_proc (by calling GC_set_push_other_roots()) to a function that knows how to find all the sections of all the thread stacks. GC_push_other_roots_proc is called once at the start of every GC, so it is ideal for things such as stacks that are likely to be different sizes and locations at every GC.</div><div><br></div><div>See the comments in include/private/gc_priv.h</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 4:46 PM, Hans Boehm <span dir="ltr"><<a href="mailto:boehm@acm.org" target="_blank">boehm@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think this will require work to correctly scan such stacks.  AFAIK, the collector currently assumes that thread stacks are contiguous.  The current thread stopping code may also need work to perform reasonably for large numbers of (hopefully mostly blocked) threads.<span class="HOEnZb"><font color="#888888"><div><br></div><div>Hans</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 7:43 PM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 05, 2014 at 10:01:26AM +1000, Julien Fischer wrote:<br>
><br>
> Hi,<br>
><br>
> Has anyone tried Mercury (particularly the high-level C grades) with<br>
> GCC's split stacks capability?  See: <<a href="https://gcc.gnu.org/wiki/SplitStacks" target="_blank">https://gcc.gnu.org/wiki/SplitStacks</a>>.<br>
><br>
<br>
The trade offs seem interesting, not that they're trying to economise on<br>
address space usage, especially on 32bit systems.  On a 64bit system this<br>
isn't a big deal for C programs as only the parts of the stack that actually<br>
get used get mapped to actual physical pages.<br>
<br>
There may also be interesting interactions with the Boehm collector.  Will<br>
BoehmGC be able to scan these stacks?<br>
<br>
I've cross-posted this to the Boehm GC list as it may be interesting for<br>
the GC's developers.<br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
Paul Bone<br>
_______________________________________________<br>
bdwgc mailing list<br>
<a href="mailto:bdwgc@lists.opendylan.org" target="_blank">bdwgc@lists.opendylan.org</a><br>
<a href="https://lists.opendylan.org/mailman/listinfo/bdwgc" target="_blank">https://lists.opendylan.org/mailman/listinfo/bdwgc</a><br>
</font></span></blockquote></div><br></div>
<br>-- 
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.

</div></div><br>_______________________________________________<br>
bdwgc mailing list<br>
<a href="mailto:bdwgc@lists.opendylan.org">bdwgc@lists.opendylan.org</a><br>
<a href="https://lists.opendylan.org/mailman/listinfo/bdwgc" target="_blank">https://lists.opendylan.org/mailman/listinfo/bdwgc</a><br></blockquote></div><br></div>