On Fri, Feb 3, 2012 at 5:24 PM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
>
> This confusese two things: (1) the existence of a stack; (2) the
> direction of growth.
> The test for (2) is invoking an undefined behaviour. Therefore, the
> outcome of
> that test does not say anything about the collector's assumption that
> there is
> a stack (1) and a defined direction of growth.
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
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...
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.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
