forcing weak purity
Steven Schveighoffer
schveiguy at yahoo.com
Wed May 23 08:56:42 PDT 2012
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
More information about the Digitalmars-d
mailing list