On Tuesday, 20 January 2015 at 21:47:34 UTC, ketmar via Digitalmars-d wrote:
> and the funniest thing that it is perfectly able to do that! all the code is already there.

Yes. But, destructors should be removed for GC anyway...  it is a GC performance killer. So maybe it is better that they stay unreliable, politically... :-]

On Tuesday, 20 January 2015 at 20:51:18 UTC, Steven Schveighoffer wrote:
> On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
>
>> and all that mess can be avoided just by enforcing the one simple rule,
>> which compiler is perfectly able to check.
>
> I think the current situation is fine.
>
> 1. There are functions that sometimes allocate. I don't want to forbid those, or force someone to write @nogc versions.
> 2. One can invoke destructors without being inside the GC.
>
> This seems like a good job for a lint tool.
>
> -Steve

+1

If you want to fix something, fix the possibility to escape
the this reference. The @nogc thing is simply an limitation of the implementation of the GC.

On Tuesday, 20 January 2015 at 21:37:56 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer wrote:
>> How's that? The current runtime aborts on memory allocation inside the GC collection routine, it's not a memory safety issue.
>
> Spurious race conditions in memory deallocation patterns that remain undetected and cause random crashes after deployment are ok? That is not memory safety, it is "memory safety".
>
> The language should prevent this.

That is GC implementation issue, not a language issue. If it ain't broken, don't fix it.

On Tuesday, 20 January 2015 at 22:10:36 UTC, deadalnix wrote:
> That is GC implementation issue, not a language issue. If it ain't broken, don't fix it.

Efficient GC with compile time safety is a language issue. Current Class allocation and deallocation patterns are making fast collection unlikely IMHO.

On Tuesday, 20 January 2015 at 22:16:31 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 20 January 2015 at 22:10:36 UTC, deadalnix wrote:
>> That is GC implementation issue, not a language issue. If it ain't broken, don't fix it.
>
> Efficient GC with compile time safety is a language issue. Current Class allocation and deallocation patterns are making fast collection unlikely IMHO.

Any serious GC can run concurrently (instead of stopping the world). That mean any serious GC must be able to handle allocations while collecting.

Not only handling these case is unlikely to make the GC any slower, but in fact, this is required to make the GC faster.

On Tuesday, 20 January 2015 at 22:25:05 UTC, deadalnix wrote:
> Any serious GC can run concurrently (instead of stopping the world). That mean any serious GC must be able to handle allocations while collecting.

Concurrent GC is too expensive for a proper system level language. Stopping the thread/world is OK if you:

1. Statically determine what you need to scan to get full coverage (by static typing) so that you discriminate/classify pointers effectively.

2. Cluster all the pointers that needs scanning on the same cache lines by design.

3. Use exact (precise) scanning.

4. Use a collector that is carefully written for cache locality and minimize cache misses using batching.

5. Generate the runtime to take advantage of information from pre-linking static analysis.

Remember that the memory bus can push up to 6GB/s. So in 5ms you can read up to 30MB, which is roughly 400.000 cache lines. So, you should be able to do fine with 50-100.000 GC allocated objects.

That means a mix of regular heap and GC convenience is possible, even in a real time app, but you have to design for it all the way around (inclusive language constructs).

> Not only handling these case is unlikely to make the GC any slower, but in fact, this is required to make the GC faster.

Deallocators means you have to track object boundaries and make partial deallocation (deallocating a class instance except a live member that still has a reference to it) more tricky.

K.I.S.S. + limited use of GC + GC designed language constructs + good static analysis + generated runtime => fast collection if you write for it.

On Tuesday, 20 January 2015 at 23:00:26 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 20 January 2015 at 22:25:05 UTC, deadalnix wrote:
>> Any serious GC can run concurrently (instead of stopping the world). That mean any serious GC must be able to handle allocations while collecting.
>
> Concurrent GC is too expensive for a proper system level language.
>

That is an unsubstanciated claim.

On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
>> Concurrent GC is too expensive for a proper system level language.
>>
>
> That is an unsubstanciated claim.

And so is «pigs can't fly».

You want to run the collection when the GC-memory is hot in caches. That basically means you want to run it right after you have traversed the data structure. E.g. clean up dead long lived objects after an iteration in a simulation.

A concurrent GC will slow you down, push you out of (soft) real time boundaries and keep dragging irrelevant stuff into the caches.

You want a fast and predictable GC that can fire often, not a slow "interleaved one" (one way or the other you need to compensate).

On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via Digitalmars-d wrote:
> let's see how this proposal will be rejected. will there be some sane
> reasons, or only the good old song about "broken code"? make your bets!

Lots of functions can theoretically allocate, but don't in the way you call them. For example, a function that checks for invalid arguments and throws an exception if any are passed in. It can't be @nogc because it throws, but it's perfectly valid to call in a constructor.

Also, what about classes allocated with malloc/emplace that are then destroyed/freed?

On Wed, 21 Jan 2015 00:29:21 +0000
Kapps via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via Digitalmars-d wrote:
> > let's see how this proposal will be rejected. will there be
> > some sane
> > reasons, or only the good old song about "broken code"? make
> > your bets!
> 
> Lots of functions can theoretically allocate, but don't in the way you call them. For example, a function that checks for invalid arguments and throws an exception if any are passed in. It can't be @nogc because it throws, but it's perfectly valid to call in a constructor.
nothing is valid with calling even potentially allocating function in dtor.

> Also, what about classes allocated with malloc/emplace that are then destroyed/freed?
that's easy: mark that destructors with proposed `@gc` attribute. this way you will explicitly tell the compiler that you know what you're doing here and taking all responsibility for your actions.