• tcak (12/12) Nov 17 2015 As far as I know, GC has a separate thread that stops all other
• Adam D. Ruppe (3/8) Nov 17 2015 This is what it actually does now.
• Chris Wright (4/14) Nov 17 2015 And, as I understand it, it will only trigger a collection if it doesn't...
• tcak (6/14) Nov 17 2015 That means object destructors are to be called only when a new
• Minas Mina (5/23) Nov 17 2015 That's correct.
• Gary Willoughby (3/7) Nov 18 2015 or scoped:
• Kagamin (2/5) Nov 18 2015 It only runs the destructor, it doesn't free memory.
• Adam D. Ruppe (4/6) Nov 18 2015 For things allocated with the gc, yes, though remember that isn't

tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:

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.

Adam D. Ruppe <destructionator gmail.com> writes:

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.

Chris Wright <dhasenan gmail.com> writes:

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.

tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:

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.

Minas Mina <minas_0 hotmail.co.uk> writes:

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.

Gary Willoughby <dev nomad.so> writes:

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.



or scoped:

Kagamin <spam here.lot> writes:

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.

Adam D. Ruppe <destructionator gmail.com> writes:

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.