D GC theory

[ketmar via Digitalmars-d]

On Mon, 23 Feb 2015 21:11:22 +0000, Sativa wrote:

> How hard would it be to modify D's GC to do the following two things:
> 
> 1. Scan the heap in the BG on another thread/cpu for compactification.

needs read/write barriers added to generated code. a major slowdown for 
ALL memory access.

> 2. Move blocks of memory in predictable(timewise) chunks that prevents
> locking the main thread for any period of time.

as you can't do "partial scans" without barriers... see above.

> e.g., in the first step the GC finds some blocks of memory that need to
> be freed/compacted. In the 2nd step it starts freeing/compacting it in
> predictable pieces by limiting the time it takes while working.

it's not freeing that takes time, it's scanning that takes time. after 
scanning is complete there is not much left to do. ah, well, if you have 
thousands of small objects, this can be slow too, but with such use case 
partial frees will lead to OOM situations very fast (as your code have to 
allocate as crazy to get to such situation).

tl;dr: you can't do this in compiled language without introducing major 
slowdown for indirect memory access. and indirect memory access is used 
*everywhere*. you will not like the results.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150224/9d0a5134/attachment-0001.sig>