[D-runtime] Precise garbage collection

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 24 11:28:57 PDT 2013


On Jun 24, 2013, at 2:04 PM, Rainer Schuetze <r.sagitario at gmx.de> wrote:

> On 24.06.2013 16:40, Steven Schveighoffer wrote:
>> 
>> Here is a possibility for rectifying: any time you share immutable
>> data by reference, the compiler generates a call to some
>> 'makeImmutableArrayShared' function with the pointer, and that
>> removes the block's APPENDABLE bit (if part of the GC).  That would
>> make any immutable shared arrays truly immutable, and avoid this
>> problem.
>> 
>> Thoughts?  Is it possible to intercept the moment immutable data
>> becomes shared?
> 
> I think you can make the length update lock- and race-free with a single CAS operation on the length, that pretty much does what is currently done in __setArrayAllocLength. You don't even have to care for problems like ABA, as the size always increases.
> 

This doesn't solve the problem that we cannot use thread-local caching of blockinfos for immutable and const array types (the main source of the speedup).

assumeSafeAppend can decrease the size, also.

> The cost of adding this to the non-shared code path aswell (or better not making the distinction at all) is propably more than offset by removing the tests for sharedness.

BTW, we can solve this problem by just making the compiler do the work, or making it instantiate a template to do the work of determining sharedness :)  The only reason I'm checking for sharedness in the function at runtime is because that's what the compiler gives me.

-Steve


More information about the D-runtime mailing list