DIP60: @nogc attribute

[via Digitalmars-d]

On Thursday, 17 April 2014 at 13:43:17 UTC, Manu via 
Digitalmars-d wrote:
> You would never allocate in a ray tracing loop. If you need a 
> temp, you
> would use some pre-allocation strategy.

Path-tracing is predictable, but regular ray tracing may spawn 
many rays per hit. So you pre-allocate a buffer, but might need 
to extend it.

The point was: RC-per-object is unacceptable.

>> And it is slower and less more "safe" than GC for long running 
>> servers that have uneven loads. E.g. web services.
>
> Hey? I don't know what you mean.

1. You can get memory leaks by not collecting cycles with RC.

2. You spend time RC accounting when you need speed and run idle 
when you could run GC collection. GC is faster than ARC.

>> Best strategy is global GC.
>
> You can't have web servers locking up for 10s-100s of ms at 
> random intervals... that's completely unacceptable.

The kind of servers I write can live with occasional 100-200ms 
lockups. That is no worse than the time it takes to get a 
response from a database node with a transaction running on it.

For a game server that is too much so you would need to get down 
to under ~50ms, but then you also tend to run with a in-memory 
database that you cannot run full GC frequently on because of all 
the pointers in it.

> D doesn't usually have compilation unit boundaries.

It does if you need multiple entry/return paths. E.g. need to 
compile 2 different versions of a function depending on the 
context. You don't want a copy in each object file.

> I find strings are often highly shared objects.

Depends on how you use them. You can usually tie them to the 
object "they describe".

>> What benefits most from GC are the big complex objects that 
>> have lots of
>> links to other objects, so you get many circular references.
>>
>> You usually have fewer of those.
>>
>
> These tend not to change much at runtime.

On the contrary, content objects are the ones that do change both 
in terms of evolutionary programming which makes it easy to miss 
a cycle, and at runtime.

This is especially true for caching web-servers, I think.

> Also, I would mark weak references explicitly.

Which can be difficult to figure out and then you also have to 
deal with "unexpected null references" and the exceptions it 
might cause.

Weak references can be useful with GC too if the semantics are 
right for the situation, but it is a crutch if it is only used 
for killing cycles.

> Well it's still not clear to me what all the challenges are... 
> that's my
> point. If it's not possible, I want to know WHY.

I think it is possible, but I also think shipping D2 as a 
maintained stable product should have first priority. ARC would 
probably set D back one year? I think that would be a bad thing.

Ola.