System.Byte[] ... Should be dispossed somhow?

Posted by OctavioOlguin on 03-Mar-2017 09:46

Greetings.   I'm very excited about all the knowledge you all have help me to get this past days...  I thank you all.

One of the things I'm getting grasp on, is the .Net objects... And this first class I have, i've being refining more and more.  Now came to this..

In order of to keep this program running long, should I have to dispose the vars I define as System.Byte[], between calls to the methods that use some iterations of those vars?  This is: If I've done with a var in some point, should i:

systemByteVar1 = ?.

Or I can think of them being collected as some native datatype var?

Posted by Brian K. Maher on 03-Mar-2017 11:10

Octavio,
 
I believe you will be okay and this will get GC’d.
 
You may want to consider using the -clientlog, -logginglevel and -logentrytypes startup parameters and setting -logentrytypes to DynObjects.Class as this will log instantiation and deletion of class instances.  This logging should help you answer these sorts of questions.
 
Brian

All Replies

Posted by Peter Judge on 03-Mar-2017 09:50

Generally speaking, objects (OOABL-only) are garbage collected when the variable/temp-table row holding them goes out of scope, or when the values in the variables are replaced by another.
 
So in a loop if you assign systemByteVar1 a value, then in the next iteration of the loop yo assign it another value. The first value is GC’ed (ceteris paribus/all other things being equal).
 

Posted by OctavioOlguin on 03-Mar-2017 10:43

Tanks that it's clear and noticed,

but my question goes more in this use-case:

on ABL, a class is instantiated with a Byte[] defined as global to the class, then a method inside is called.  This method happens to use that Byte[], does stuff on it, included, it is sended to a method that does this on it:

 METHOD PRIVATE STATIC MEMPTR ByteArrayToMemptr (poBytes AS "System.Byte[]":U):
 
        DEFINE VARIABLE myMemptr    AS MEMPTR        NO-UNDO .
        DEFINE VARIABLE oIntPointer AS System.IntPtr NO-UNDO .
 
        SET-SIZE (myMemptr) = poBytes:Length .
        oIntPointer = NEW System.IntPtr (GET-POINTER-VALUE (myMemptr)).
        System.Runtime.InteropServices.Marshal:Copy (poBytes, 0, oIntPointer, poBytes:Length).
        RETURN myMemptr.
 
        FINALLY:
            DELETE OBJECT oIntPointer.
        END FINALLY.
 
    END METHOD .

 

and the System.IntPtr should be explicity DELETEd inside the method.

Then at return, the Byte[] in question it is handled and the method returns control to UIB ABL... 

My question is, that Byte[], for the next iteration/use of the method, should be emptyr'd first? (or otherwise, at return from former method, asigned to ?)...

 

Posted by OctavioOlguin on 03-Mar-2017 10:56

Well,, infact I missed to elaborate more on this situation, and perhaps that shows why is my dubitation...

Inside those methods on this class. it is performed this, as a reverting process to the anterior posted manipulation:

METHOD PRIVATE STATIC "System.Byte[]" MemptrToByteArray( pmptr AS MEMPTR ):
        DEFINE VARIABLE nPtr   AS System.IntPtr   NO-UNDO.
        DEFINE VARIABLE vInt   AS INTEGER         NO-UNDO.
        DEFINE VARIABLE nBytes AS "System.Byte[]".
     
        vInt = GET-SIZE(pmPtr).
        nBytes = NEW "System.Byte[]"(vInt).
        nPtr = NEW System.IntPtr(GET-POINTER-VALUE(pmPtr)).
        System.Runtime.InteropServices.Marshal:Copy(nPtr, nBytes, 0, vInt).
     
        RETURN nBytes.
        FINALLY:
            nPtr = ?.
            set-size(pmPtr) = 0.
            nBytes = ?.
        END.
         
    END METHOD.
   // - See more at: community.progress.com/.../100235

Notice the explicit SET-SIZE(pmPtr).

That's why I have doubt about the System.Byte[] needed some special handling after use...

Posted by Brian K. Maher on 03-Mar-2017 11:10

Octavio,
 
I believe you will be okay and this will get GC’d.
 
You may want to consider using the -clientlog, -logginglevel and -logentrytypes startup parameters and setting -logentrytypes to DynObjects.Class as this will log instantiation and deletion of class instances.  This logging should help you answer these sorts of questions.
 
Brian

Posted by OctavioOlguin on 03-Mar-2017 12:23

Thanks... I'll do as told....

This thread is closed