Q: Delete vs Close of NOXDB memory

[wimjongman]

We have questions about the management of the created NOXDB objects.

Suppose we have a CGi program that does not dispose of the objects created by NOXDB. What will be the longer-term effect of this?

Do we always need to delete every object that we create? Is there a list of pointers available that were not disposed of? Can we do mass disposal of all objects when the call is done? What is the relation between close and delete?

[NielsLiisberg]

Hello Wim;

ILE is not like Java - so no garbage collector:

Do we always need to delete every object that we create? yes

Is there a list of pointers available that were not disposed of? no. - and yes; IBM provides a logging mechanism for all memory used, look this feature up;

ADDENVVAR ENVVAR(QIBM_MALLOC_TYPE) VALUE('DEBUG') LEVEL(JOB) REPLACE(YES)

Can we do mass disposal of all objects when the call is done? Yes "Segments" was introduced - but i'll not recommend using that - it just created confusion; Rather use RCLACTGRP - and what ever activation group you have put noxDB into - normally it will QILE out of the box.

What is the relation between close and delete?

delete: removes the current node and recursively all ies children. close: travels to the top of the tree and issues a delete .

Look at the examples using memleak - it will show how much memory you have assigned and what you have not delivered back

On Thu, Dec 15, 2022 at 12:03 PM Wim Jongman @.***> wrote:

We have questions about the management of the created NOXDB objects.

Suppose we have a CGi program that does not dispose of the objects created by NOXDB. What will be the longer-term effect of this?

Do we always need to delete every object that we create? Is there a list of pointers available that were not disposed of? Can we do mass disposal of all objects when the call is done? What is the relation between close and delete?

— Reply to this email directly, view it on GitHub https://github.com/sitemule/noxDB/issues/76, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVIPHTPKCVGAUAIP6SSP2LWNL3JJANCNFSM6AAAAAAS7S4FBA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[wimjongman]

Thanks, Niels,

I was wondering if NOXDB was keeping a list of all mallocs so we could do a jx_FreeAll or something similar.

[NielsLiisberg]

It does already - look at the "segments"

example JSONPARS9

everything you create between a json_SegmentSelectNo and json_SegmentDispose is kept track of

      pSegment1 = json_SegmentSelectNo(1);
      //DO STUFF
      json_SegmentDispose(pSegment1);

But I will not recommend it - it was introduced to embrace exactly what you are asking for. But think about it for a moment: if you start moving objects around in the object graph - you will have "magic code" deleting the objects and arrays - and you are totally lost.

We got a lot of "issues" after developers were starting to use it and it always went back to code-misuse.

It is discontinued for the same reasons in the UTF-8 branch.

Keep your stack clean - it my best advice use the json_memstat();

On Mon, Dec 19, 2022 at 12:09 PM Wim Jongman @.***> wrote:

Thanks, Niels,

I was wondering if NOXDB was keeping a list of all mallocs so we could do a jx_FreeAll or something similar.

— Reply to this email directly, view it on GitHub https://github.com/sitemule/noxDB/issues/76#issuecomment-1357474169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVIPHRVIASCSMPON47PHT3WOA65DANCNFSM6AAAAAAS7S4FBA . You are receiving this because you commented.Message ID: @.***>