Garbage Collector?

[Ben via Digitalmars-d]

On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner wrote:
> You replied to the wrong person here, seeing as I did not link 
> to the article you're referring to,

Sorry...

> so I'll reply:
> Expanding the continuous memory region a dynamic array consists 
> of (possibly moving it) once it overflows has absolutely 
> nothing to do with the GC, or even the language, it's how the 
> abstract data type "dynamic array" is defined. D just does this 
> transparently for you by default. If you already know the exact 
> or maximum size, you can allocate *once* (not 6 times) using 
> `new` and `.reserve` respectively *before* entering the loop, 
> like that article explains in depth.

You seem to be missing the fact that i pointed this out. The fact 
that the GC might have done up to 6 collection rounds in that 
loop is "ludicrous".

>
> Um, what? Memory (de)allocation (in C often malloc/free) and 
> object (de)contruction (in C usually functions with some naming 
> conventions like `type_init`/`type_deinit`) are on two entirely 
> different layers! Granted, they are often combined in C to 
> functions with names like `type_new`/`type_free`, but they are 
> conceptually two distinct things. Just to be very clear, here 
> is a primitive diagram of how things work:
> make object O of type T:
> <OS> --(allocate N bytes)--> [memory chunk M] --(call 
> constructor T(args) on M)--> [O]
> dispose of O:
> [O] --(call destructor ~T() on O)--> [memory chunk M] 
> --(deallocate M)--> <OS>
>
> D's garbage collector conceptually changes this to:
> make object O of type T:
> <OS> --(GC allocates)--> [GC memory pool] --(allocate N 
> bytes)--> [memory chunk M] --(call constructor T(args) on M)--> 
> [O]
> dispose of O:
> [O] --(call destructor ~T() on O)--> [memory chunk M] 
> --(deallocate M)--> [GC memory pool] --(GC deallocates)--> <OS>
> with the specific restriction that you have *no* control over 
> 'GC deallocates' and only indirect control over 'GC allocates' 
> (by allocating more memory from the GC than is available its 
> the pool).
>
> Working on the memory chunk layer is memory management.
> Working on the object layer is object lifetime management.
> D offers you both automatic memory management and automatic 
> lifetime management via its GC.
> What you describe is manual object lifetime management (which 
> is what std.conv.emplace and object.destroy exist for) and has 
> no effect on the automatic memory management the GC performs.
> You *can* do manual memory management *on top* of the GC's 
> memory pool (using core.memory.GC.{alloc/free) or the newer, 
> generic Alloactor interface via 
> std.experimental.allocator.gc_allocator.GCAllocator.{allocate/deallocate}), but these operations will (generally) not yield any observable difference from the OS's perspective.
>
>>
>> That is assuming the GC removes the memory reference when you 
>> call it. I remember seeing in some other languages ( C# 
>> possibly? ) that referring a variable to be freed only meant 
>> the GC freed the memory when it felt like it, not the exact 
>> spot when you told it.
>
> Again, you seem to mix object lifetime management and memory 
> management. You cannot tell the GC to free memory back to the 
> operating system (which is what the free syscall does and what 
> you seem to be describing). You can *only* free memory you 
> allocated *from* the GC *back* to the GC. The GC decides when 
> (and if) any memory is ever being freed back to the OS (which 
> is kinda one major point of having a GC in the first place).

I know, i do not express myself very well in English.

> In my experience most people's aversion to GCs can be aptly 
> described by the German proverb "Was der Bauer nicht kennt, das 
> frisst er nicht" (the meaning of which being that most people 
> generally like living in comfort zones and rarely - if ever - 
> dare to leave them of their own free will; that includes 
> developers, sadly).

Unfortunately i do have plenty of experience with GC kicking in 
on the wrong moments ( or not at the right moments, people forget 
that one ).

I am sure that the amount of people who develop in GC languages 
is much bigger these days then manual managed languages ( what is 
more or less a rarity these days among the new languages ). Even 
Rust still has some background management going on ( like the 
byte counter ).

Maybe its my opinion only but a good language will not put 
anything in the way of the developer but will point out mistakes.

The Rust compiler is not a bad example but it can be taken a step 
more. Is it so hard for developers when you declare a variable, 
to later also clean it up???

var x = 1;
// Do work
x.free;

Easy ... Sure, it becomes a little bit more tricky with ownership 
but that is where the compiler can help and simply state: "Hey, 
you forgot this variable, it does not seem to be used beyond this 
point". Just calling the x.free seem to be too much work for 
developers these days.

Up to now i found very few languages that did this correctly. But 
this is a offtopic discussion.