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 <#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 <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVIPHRVIASCSMPON47PHT3WOA65DANCNFSM6AAAAAAS7S4FBA> . You are receiving this because you commented.Message ID: ***@***.***>