Vladimir Panteleev, el 24 de May a las 09:55 me escribiste:
> >When the GC is run:
> >- Use VirtualProtect to mark all mutable memory pages as read-only
> >- Add a vectored exception handler to handle the access violation
> >exception
> >- Resume the GC thread
> 
> I've tried writing a generational GC for D that used page protection for write barriers a while ago. IIRC, I ran into performance issues (the page faults were rather expensive).

Yeah, using memory protection to do what fork does manually is a known approach, discussed even in the "Garbage Collection" book[1].

The good thing about fork is it's sooooo much easier to implement, and the OS is already highly tuned to do this for you. That's why, even when it might be good to explore, is not a very tempting approach for me (but I have it in mind as an alternative way to "fix" the potential deadlock caused by glibc internal mutex).

> This approach does have the benefit that it will not cause pages that have been moved to swap to be pulled out in order to be scanned every time, though.

[1] http://books.google.de/books/about/Garbage_Collection.html?id=UdtQAAAAMAAJ&redir_esc=y

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se ha dicho tanto que las apariencias engañan
Por supuesto que engañarán a quien sea tan vulgar como para creerlo

On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote:
> On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote:
>> I'd like to know if there is interest in a precise garbage
>> collector.
>
> There is interest in it, and Rainer Schütze did a talk on it at DConf. At the
> current pace (assuming that Andrei actually posts one on Monday even though
> it's a federal holiday in the US), it'll be posted on June 3rd (and if he
> skips Monday, then it'll probably be June 5th). And actually, the precise GC
> changes stand a much better chance of making it into druntime in the short
> term than any concurrency changes do.
>
> - Jonathan M Davis

That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a "deal breaker" for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon.

-- Brian

On Monday, 27 May 2013 at 17:56:10 UTC, Brian Rogoff wrote:
> On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote:
>> On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote:
>>> I'd like to know if there is interest in a precise garbage
>>> collector.
>>
>> There is interest in it, and Rainer Schütze did a talk on it at DConf. At the
>> current pace (assuming that Andrei actually posts one on Monday even though
>> it's a federal holiday in the US), it'll be posted on June 3rd (and if he
>> skips Monday, then it'll probably be June 5th). And actually, the precise GC
>> changes stand a much better chance of making it into druntime in the short
>> term than any concurrency changes do.
>>
>> - Jonathan M Davis
>
> That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a "deal breaker" for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon.
>
> -- Brian

It's actually possible to improve the precision of the GC without any additional type info. As long as you can give some unique ID to each type when you allocate it then the GC can learn the layout of that type on the fly.

For example a simple algorithm would be:
- When a new ID is first see create new type-info that is all pointers.
- While scanning an instance of that type, if a pointer points to a value in the higher half, or a sufficiently low value which is not equal to zero, then remove this pointer from the type-info.

You would have to disable this for unions, but for the rest it should work fine. Plus with more intelligent algorithms you can handle more cases. You could even save the type-info to a file and reuse it later to improve performance.