www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Non-freeing GC memory management

reply 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.
Nov 17 2015
parent reply 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.
Nov 17 2015
next sibling parent 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.
Nov 17 2015
prev sibling parent reply 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.
Nov 17 2015
next sibling parent reply 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.
Nov 17 2015
parent 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:
Nov 18 2015
prev sibling next sibling parent 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.
Nov 18 2015
prev sibling parent 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.
Nov 18 2015