forcing weak purity

[Alex Rønne Petersen]

On 23-05-2012 19:19, deadalnix wrote:
> Le 23/05/2012 18:22, Alex Rønne Petersen a écrit :
>> On 23-05-2012 17:56, Steven Schveighoffer wrote:
>>> On Wed, 23 May 2012 11:41:00 -0400, Alex Rønne Petersen
>>> <alex at lycus..org> 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.
>>
>
> If the pure function allocate a ton of memory, one of these allocation
> will trigger the collection. Why is that an issue ?

Not with the scheme Steven first proposed, but it will with his 
clarification, so all is good.

That said, I'm really not convinced it's worth the effort, but as long 
as a "pure GC" doesn't start breaking my programs, I won't complain. ;)

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org