<div class="gmail_quote">On Fri, Feb 3, 2012 at 5:24 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
</div>This confusese two things: (1) the existence of a stack; (2) the<br>
direction of growth.<br>
The test for (2) is invoking an undefined behaviour.  Therefore, the outcome of<br>
that test does not say anything about the collector's assumption that there is<br>
a stack (1) and a defined direction of growth.</blockquote></div><br>Actually, both things are related. The collector uses the same logic. It assumes that there is a stack (1) and it assumes that when GC is invoked, the address that it currently has (a) can be retrieved by looking at the closest atomic variable and (b) it can be compared with a similarly retrieved address found at the thread's entry point<div>

<br></div><div>This is what I have always found in all the versions I have reviewed, except for some platforms that offer an API to retrieve that information from different threads. It is also the reason why the GC has some funny API, intercepting calls to pthread_create() and providing functions to "import" a current thread...<div>

<br></div><div>So yes, I know that the assumption that automatic variables and call frames are sorted is based on a de-facto standard and could be broken, but right now there is no other way which does not involve nonportable assembly code and changing the GC library as well.</div>

<div><br></div><div>Juanjo<br><div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div></div></div>