www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Invoke garbage collector?

reply Sean Eskapp <eatingstaples gmail.com> writes:
I'm having an unfortunate DSFML issue, where failing to free objects like
Images or Sprites causes exceptions to eventually be thrown. Calling the
built-in member dispose() causes access violations, so I assume it's not for
programmer use.

However, I need the resources to be freed more quickly than the GC is
apparently doing (I assume the Images and Sprites are eventually cleaned up),
so is there a way to invoke a GC cleanup in some way?
Feb 09 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Eskapp:


 so is there a way to invoke a GC cleanup in some way?


http://www.digitalmars.com/d/2.0/phobos/core_memory.html#minimize

Bye,
bearophile
Feb 09 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 Feb 2011 15:58:13 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:


 Sean Eskapp:


 so is there a way to invoke a GC cleanup in some way?


 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#minimize


This attempts to minimize memory, it does not run a collection cycle (I  
don't think anyways).  To invoke the GC collector, use:

http://www.digitalmars.com/d/2.0/phobos/core_memory.html#collect

-Steve
Feb 09 2011
next sibling parent Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 09 Feb 2011 15:58:13 -0500, bearophile <bearophileHUGS lycos.com>
 wrote:

 Sean Eskapp:


 so is there a way to invoke a GC cleanup in some way?


 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#minimize


 This attempts to minimize memory, it does not run a collection cycle (I
 don't think anyways).  To invoke the GC collector, use:
 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#collect
 -Steve


Works great, thanks!
Feb 09 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/09/2011 10:15 PM, Steven Schveighoffer wrote:

 On Wed, 09 Feb 2011 15:58:13 -0500, bearophile <bearophileHUGS lycos.com>
wrote:


 Sean Eskapp:


 so is there a way to invoke a GC cleanup in some way?


 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#minimize


 This attempts to minimize memory, it does not run a collection cycle (I don't
 think anyways). To invoke the GC collector, use:

 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#collect

 -Steve


But won't this blindly run a GC cycle? What if all I want is a given thingy's 
mem to be released, isn't it overkill to call GC.collect?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 10 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Feb 2011 07:34:53 -0500, spir <denis.spir gmail.com> wrote:


 On 02/09/2011 10:15 PM, Steven Schveighoffer wrote:

 On Wed, 09 Feb 2011 15:58:13 -0500, bearophile  
 <bearophileHUGS lycos.com> wrote:


 Sean Eskapp:


 so is there a way to invoke a GC cleanup in some way?


 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#minimize


 This attempts to minimize memory, it does not run a collection cycle (I  
 don't
 think anyways). To invoke the GC collector, use:

 http://www.digitalmars.com/d/2.0/phobos/core_memory.html#collect

 -Steve


 But won't this blindly run a GC cycle? What if all I want is a given  
 thingy's mem to be released, isn't it overkill to call GC.collect?


Then you can free it via:  
http://www.digitalmars.com/d/2.0/phobos/core_memory.html#free

The OP's question was "how do I run the garbage collector".

-Steve
Feb 10 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 However, I need the resources to be freed more quickly than the GC is
 apparently doing


You could use scoped instances if you need to clean them up soon after  
creation.
Feb 09 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Trass3r (un known.com)'s article

 However, I need the resources to be freed more quickly than the GC is
 apparently doing


 You could use scoped instances if you need to clean them up soon after
 creation.


To my knowledge, these are being removed from the language, and so, could only
be
used in the short-term.
Feb 09 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 09 February 2011 17:52:47 Sean Eskapp wrote:

 == Quote from Trass3r (un known.com)'s article
 

 However, I need the resources to be freed more quickly than the GC is
 apparently doing


 
 You could use scoped instances if you need to clean them up soon after
 creation.


 
 To my knowledge, these are being removed from the language, and so, could
 only be used in the short-term.


Yes. They're inherently unsafe because of the risk of escaped references. 
std.typecons.scoped is intended as an alternative however, if you really want 
it. Personally, I'd generally advise against it unless profiling shows that you 
need it.

- Jonathan M Davis
Feb 09 2011
prev sibling parent reply Johannes Pfau <spam example.com> writes:
Sean Eskapp wrote:

I'm having an unfortunate DSFML issue, where failing to free objects
like Images or Sprites causes exceptions to eventually be thrown.
Calling the built-in member dispose() causes access violations, so I
assume it's not for programmer use.

However, I need the resources to be freed more quickly than the GC is
apparently doing (I assume the Images and Sprites are eventually
cleaned up), so is there a way to invoke a GC cleanup in some way?


I don't think that invoking the garbage collector is a good solution in
this case. "dispose" is indeed defined as "protected", so you probably
should not call it manually, but then there really should be a public
dispose like function. The reason for the crashes when calling
dispose manually is simple: dispose calls a c sfml function to release c
resources. The destructor calls dispose again, dispose tries to free an
invalid pointer -> crash. So what should probably be done is to define a
private m_disposed member and only call dispose if it hasn't been called
before. Try to add this code to the DSFMLObject class in
dsfml/system/common.d:

-------------------------------------
private:
    bool m_disposed =3D false;

public:
    final void releaseRessources() //Needs a better name, though
    {
        if(m_disposed)
            return;
        dispose();
        m_disposed =3D true;
    }
-------------------------------------

And change dispose() in the DSFmLObject ~this() to releaseRessources();

(Crashes might still occur if dispose is called directly. In the end,
this might need a little more thinking, but that's up to the DSFML
authors ;-))
--=20
Johannes Pfau
Feb 10 2011
parent Johannes Pfau <spam example.com> writes:
Johannes Pfau wrote:

Sean Eskapp wrote:

I'm having an unfortunate DSFML issue, where failing to free objects
like Images or Sprites causes exceptions to eventually be thrown.
Calling the built-in member dispose() causes access violations, so I
assume it's not for programmer use.

However, I need the resources to be freed more quickly than the GC is
apparently doing (I assume the Images and Sprites are eventually
cleaned up), so is there a way to invoke a GC cleanup in some way?


I don't think that invoking the garbage collector is a good solution in
this case. "dispose" is indeed defined as "protected", so you probably
should not call it manually, but then there really should be a public
dispose like function. The reason for the crashes when calling
dispose manually is simple: dispose calls a c sfml function to release
c resources. The destructor calls dispose again, dispose tries to free
an invalid pointer -> crash. So what should probably be done is to
define a private m_disposed member and only call dispose if it hasn't
been called before. Try to add this code to the DSFMLObject class in
dsfml/system/common.d:

-------------------------------------
private:
    bool m_disposed =3D false;

public:
    final void releaseRessources() //Needs a better name, though
    {
        if(m_disposed || m_preventDelete)
            return;
        dispose();
        m_disposed =3D true;
    }
-------------------------------------

And change dispose() in the DSFmLObject ~this() to releaseRessources();

(Crashes might still occur if dispose is called directly. In the end,
this might need a little more thinking, but that's up to the DSFML
authors ;-))


The releaseRessources function should also check for m_preventDelete.
Updated in the quote above.
--=20
Johannes Pfau
Feb 10 2011