forcing weak purity

[Alex Rønne Petersen]

On 23-05-2012 15:17, Don Clugston wrote:
> On 23/05/12 05:22, Steven Schveighoffer wrote:
>> I have come across a dilemma.
>>
>> Alex Rønne Petersen has a pull request changing some things in the GC to
>> pure. I think gc_collect() should be weak-pure, because it could
>> technically run on any memory allocation (which is already allowed in
>> pure functions), and it runs in a context that doesn't really affect
>> execution of the pure function.
>>
>> So I think it should be able to be run inside a strong pure function.
>
> I am almost certain it should not.
>
> And I think this is quite important. A strongly pure function should be
> considered to have its own gc, and should not be able to collect any
> memory it did not allocate itself.
>
> Memory allocation from a pure function might trigger a gc cycle, but it
> would ONLY look at the memory allocated inside that pure function.

Implementing this on a per-function basis is not very realistic. Some 
programs have hundreds (if not thousands) of pure functions.

Not to mention, we'd need some mechanism akin to critical regions to 
figure out when a thread is in a pure function during stop-the-world. 
Further, data allocated in a pure function f() in thread A must not be 
touched by a collection triggered by an allocation inside f() in thread 
B. It'd be a huge mess.

And, frankly, if my program dies from an OOME due to pure functions 
being unable to do full collection cycles, I'd just stop using pure 
permanently. It's not a very realistic approach to automatic memory 
management; at that point, manual memory management would work better.

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