forcing weak purity
schveiguy at yahoo.com
Wed May 23 09:29:45 PDT 2012
On Wed, 23 May 2012 12:22:39 -0400, Alex Rønne Petersen <alex at lycus.org>
> 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
>>>> 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
>> 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.
> I still don't think my concern about pure functions allocating tons of
> memory (and thus requiring global GC to happen) has been addressed,
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