forcing weak purity

Steven Schveighoffer schveiguy at
Wed May 23 09:29:45 PDT 2012

On Wed, 23 May 2012 12:22:39 -0400, Alex Rønne Petersen <alex at>  

> On 23-05-2012 17:56, Steven Schveighoffer wrote:
>> On Wed, 23 May 2012 11:41:00 -0400, Alex Rønne Petersen
>> <alex at> wrote:
>>> On 23-05-2012 17:29, Don Clugston wrote:
>>>> Not so. It's impossible for anything outside of a strongly pure  
>>>> function
>>>> to hold a pointer to memory allocated by the pure function.
>>> Not sure I follow:
>>> immutable(int)* foo() pure
>>> {
>>> return new int;
>>> }
>>> void main()
>>> {
>>> auto ptr = foo();
>>> // we now have a pointer to memory allocated by a pure function?
>>> }
>> I think what Don means is this:
>> 1. upon entry into a strong-pure function, record a GC context that
>> remembers what point in the stack it entered (no need to search above
>> that stack), and uses its parameters as "context roots".
>> 2. Any collection performed while *in* the strong-pure function
>> explicitly will simply deal with the contexted GC data. It does not need
>> to look at the main heap, except for those original roots.
>> 3. upon exiting, you can remove the original roots, and add the return
>> value as a root, and run one final GC collection within the context.
>> This should deterministically clean up any memory that was temporary
>> while inside the pure function.
>> 4. Anything that is left in the contexted GC is assimilated into the
>> main GC.
>> Everything can be done without using a GC lock *except* the final
>> assimilation (which may not need to lock because there is nothing to  
>> add).
>> Don, why can't gc_collect do the right thing based on whether it's in a
>> contexted GC or not? The compiler is going to have to initialize the
>> context when first entering a strong-pure function, so we should be able
>> to have a hook recording that the thread is using a pure-function
>> context, no?
>> Also, let's assume it's a separate call to do pure function gc_collect,
>> i.e. we have a pure gc_pureCollect function.
>> What if a weak-pure function calls this? What happens when it is not
>> called from within a strong-pure function?
>> I still think gc_collect can be marked pure and do the right thing.
>> -Steve
> I still don't think my concern about pure functions allocating tons of  
> memory (and thus requiring global GC to happen) has been addressed,  
> though.

What I forgot is:

2a. Any collection performed *implicitly* during strong-pure function may  
run a full collection cycle.


More information about the Digitalmars-d mailing list