As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields.

Windows Vista was (Linux does as well as far as I know) making use of whole memory and not freeing the memory until more space is needed.

What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically?

If there is space (free space in heap can be tracked I guess) in heap still, there is no need to free anything. If there is no space, and there is unused memory, they can be freed first. If there is still not enough memory, finally the size of heap can be increased.

On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote:
> As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields.

That is a common misconception...

> What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically?

This is what it actually does now.

On Tue, 17 Nov 2015 19:32:03 +0000, Adam D. Ruppe wrote:

> On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote:
>> As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields.
> 
> That is a common misconception...
> 
>> What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically?
> 
> This is what it actually does now.

And, as I understand it, it will only trigger a collection if it doesn't already have any free memory of the correct size. There might be something else to ensure the collector doesn't run too often.

On Tuesday, 17 November 2015 at 19:32:05 UTC, Adam D. Ruppe wrote:
> On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote:
>> As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields.
>
> That is a common misconception...
>
>> What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically?
>
> This is what it actually does now.

That means object destructors are to be called only when a new allocation happens? But not all allocations end up with this. If this is so, this behaviour of GC encourages to call destroy (or was it clear?) on objects manually to manage the memory more efficiently.

On Wednesday, 18 November 2015 at 05:49:00 UTC, tcak wrote:
> On Tuesday, 17 November 2015 at 19:32:05 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote:
>>> As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields.
>>
>> That is a common misconception...
>>
>>> What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically?
>>
>> This is what it actually does now.
>
> That means object destructors are to be called only when a new allocation happens? But not all allocations end up with this. If this is so, this behaviour of GC encourages to call destroy (or was it clear?) on objects manually to manage the memory more efficiently.

That's correct.
But you don't have to do it manually though, as you can always wrap your object inside a Unique!T.

http://dlang.org/phobos/std_typecons.html#.Unique

On Wednesday, 18 November 2015 at 05:49:00 UTC, tcak wrote:
> If this is so, this behaviour of GC encourages to call destroy (or was it clear?) on objects manually to manage the memory more efficiently.

It only runs the destructor, it doesn't free memory.

On Wednesday, 18 November 2015 at 05:56:37 UTC, Minas Mina wrote:
> That's correct.
> But you don't have to do it manually though, as you can always wrap your object inside a Unique!T.
>
> http://dlang.org/phobos/std_typecons.html#.Unique

or scoped:

http://dlang.org/phobos/std_typecons.html#.scoped

On Wednesday, 18 November 2015 at 05:49:00 UTC, tcak wrote:
> That means object destructors are to be called only when a new allocation happens?

For things allocated with the gc, yes, though remember that isn't all things. Structs without `new` for example are automatically destroyed at end of scope.