A question about garbage collection/cleanup in PB

[SkyManager]

Hi all,

I just planning to use PB to develop a large application
which will consist of several big modules.

If I load up several big modules with numerous pop-up/ close-down complicated dialogs.

Then, my head is wondering about the issue of garbage collection (clean-up).

Do I need to programming the house-keeping tasks of monitoring the memory and perform the garbage collection (clean-up) or
does PB do this automatically for us?

[Shield]

PB does not do garbage collecting for you, you need to do everything by yourself.
So make sure you use the appropriate clean-up functions such as CloseFile(), FinishDirectory() etc.

[Fred]

While it doesn't have garbage collector, as long you don't use dynamic function like AllocateMemory(), you should be on the safe side (be sure to release the objects allocated with #PB_Any as well, as they are not reused automatically). It's way easier to manage than in C for example where you have to track every single allocation.

[BorisTheOld]

Do I need to programming the house-keeping tasks of monitoring the memory and perform the garbage collection (clean-up) or does PB do this automatically for us?

Yes.

PB does some cleanup, but you'll need to do some if your code is dynamic.

We tend to write large applications with lots of dynamic creation and destruction of resources. We've found that the following strategy works well for our class-based PB code.

All class data is stored in dynamically allocated structures, which can contain references to other dynamic structures and to PB objects allocated using #PB_Any. This can involve a lot of recursive processing, but seems to work well. In our code, these are the only items that need special attention. All standard PB data types such as strings, arrays, maps, etc, can be handled by the PB "InitializeStructure" and "ClearStructure" statements.

When creating an object:

Allocate the structure memory using - AllocateMemory(...)
Format the structure fields using - InitializeStructure(...)
Create PB object references using the #PB_Any option
Create references to other structures using the above 3 steps

When destroying an object:

Destroy references to other structures using the following 3 steps
Destroy the PB object references using - FreeGadget(...) etc
Destroy the structure fields using - ClearStructure(...)
De-allocate the structure memory using - FreeMemory(...)

[Fred]

You could also use a structured linkedlist() to handle your dynamic objects, so you don't have to AllocateMemory()/InitializeStructure() manually.

[BorisTheOld]

Yes, there are many different ways of handling garbage-collection, but the exact methods used will depend on the topology of the application.

The key thing to remember is that dynamically created objects need to be destroyed in the reverse order when doing the housekeeping manually.

[SkyManager]

Yes, I am thinking to use

a linked list with structure containing fields such as
Gadget Group, GadgetID, Time of creation, Time of last access, etc.

My follow up questions :
Has PB already recorded these information for us so that we do not need to duplicate the job?
For example, any debugging information about the object created?
Any (easy) method for us to list out all the user created objects in PB?
Or, do we need to maintain such a list by ourselves?

[TI-994A]

...I am thinking to use a linked list with structure containing fields such as
Gadget Group, GadgetID, Time of creation, Time of last access, etc.
...Has PB already recorded these information...
...Any (easy) method for us to list out all the user created objects in PB?

Hello SkyManager. PureBasic manages all of its gadgets and objects automatically. This means that every initialised gadget and created object, from loaded media to hardware resources, are managed by PureBasic, and are unconditionally freed at program end. Functions such as FreeGadget(), FreeImage(), FreeFont(), FreeMemory(), etc., only facilitate resource management and optimisation during runtime. Technically, they don't even have to be called at all as all their corresponding resources will be freed when the program terminates.

The only exceptions would be for resources not created with PureBasic functions, for example through API calls. These, PureBasic are not aware of, and as such, may not be freed automatically, and can cause memory leaks and crashes.

Do I need to programming the house-keeping tasks of monitoring the memory and perform the garbage collection (clean-up) or
does PB do this automatically for us?

So, to answer your question, if you are not really bothered with optimisations, you can leave all the housekeeping and garbage collection to PureBasic, and it will ensure the unfettered execution of your programs.

IMHO.

[SkyManager]

Thanks for TI-994A.

unconditionally freed at program end

I know that all resources will be freed at program ends.

But my requirement is NOT,
I want to free them of previously used module resources and to load new module resources
when user is trying to switch among different modules; that is, BEFORE leaving the application.

I dont mind if it is a small program.
But I am wondering for a large program with many modules.
Preloading all the modules may have potential problems and inefficient.

If I do not care for this, I am afraid that the old unused resources are still resident in the system
and that end up either slowing-down and wasting the system resources.

Unless somebody tells me that PB has a smarter way to handle this

[TI-994A]

...I am wondering for a large program with many modules.
Preloading all the modules may have potential problems and inefficient.

...I am afraid that the old unused resources are still resident in the system and that end up either slowing-down and wasting the system resources.

Hello again. Yes, it may be inefficient, but I don't believe that it would lead to any potential problems. All initialised resources will remain in memory until explicitly freed, but performance will still be proportionate to available system resources.

However, it should also be noted, that struggling with housekeeping and garbage collection while excessively pre-loading resources is simply counter-productive; it hogs up precious memory and screeches the system to a paging crawl. Instead, good memory management should be meticulously factored into the original program design, which would invariably minimise such housekeeping requirements in the first place.

Compared to other development platforms, PureBasic is intrinsically smart, but it still boils down to individual programming practices. Any tool is only as good as the person who uses it.

[BorisTheOld]

I want to free them of previously used module resources and to load new module resources
when user is trying to switch among different modules; that is, BEFORE leaving the application.

We had the same concerns. Our applications have 50 to 100 forms, many of which have hundreds of gadgets attached to them. And, since only a few forms might be used at one time, we decided to allocate resources on demand, rather than pre-allocate everything at the start of the application.

Although PB does a lot of housekeeping, it's still necessary to "help" PB by initiating cleanup. For example, clearing arrays and maps, or deleting the top-level container in a hierarchy of gadgets. But that still leaves dynamically allocated memory -- and that's where things get tricky. Anything contained in that memory has to be "released" manually, otherwise stuff might be left allocated with no way of getting rid of it. This is because things like strings and arrays only exist as pointers, with the actual data being allocated elsewhere.

To simplify the "rats nest" that might occur with all this added complexity, we treat each application as a finite state machine, and hold it all together with classes wrapped around PB gadgets, etc. Each class is responsible for creating and destroying its own resources.