FREE MEMORY

[Former Member]

Hi guys. Does anyone know why I can not use, or is not recomended to not use "free memory" command without the "ID" ? Do you have any example of why can I not simple use "Free memory" ?. I have a large program (large indeed...)that creates several internal tables, nore of them liberates memory after it finishes and when the user executes several options of the program and gets back and executes again, (WITHOUT leaving the transaction), then by transaction SM04 you can see how the memory gets bigger. I started using "free..internal table" (when I see that an internal table with data will not be used any more along the program) then the memory gets smaller after each execution, but not smaller enough for the Basis team. So instead of using free "internal table" for each table used in the program (it has too much ...internal talbes ) then I wanted to use just FREE MEMORY at the end of the program, instead of FREE MEMORY ID id. Does anyone have a practical example of why is not recomended to use only FREE MEMORY. Somewhere I saw the following: " You should refrain from using FREE MEMORY without the addition ID, since in this case all clusters are involved"- The question is: I do not understand the impact of all clusters being involved. Do you have an explanation about the impact ?

Edited by: Eduardo Giribaldi on Jan 5, 2008 1:21 PM

[Sougata]

Eduardo,

FREE MEMORY only makes sense when you do

EXPORT fld TO db ....

IMPORT fld FROM db....

otherwise not. If you are coding in ABAP OO you can clear your pointer or reference for e.g.

Data: g_ref TYPE REF to CL_ABAP_CHAR_UTILITIES.

[]............

[]............

CLEAR g_ref.    "<--------------

At this point the Garbage Collector is called automatically by the ABAP runtime system. If you are using procedural code, you can use statements like:

CLEAR v_var1.
FREE itab.
* etc.

at the end of your data processing.

Hope this gives you a lead.

Cheers,

Sougata.

[Former Member]

Hi Sougata. Actually I am using free itab and the memory gets smaller indeed. Since the large program has too many internal tables, I putted at the end of the program a routine which liberates memory for all the internal tables (one be one: free itab1, free itab2, etc) that were declared globally in the program. It works. But it has so many internal tables that were defined locally in performs that for those tables I am not using free itab since they are too many, many..and when debuging, its a little difficult to see when that particular table is not any more used for me to place the free itab at the right place for that table. That is why I wanted to used just Free Memory at the end of the program for all. Those internal tables that where defined locally in performs, you know that when exiting of those routins the table is not more used and not more recognized by the program, but the memory they used keeps used...therfeore you can use Free Memory and that is it, without the ID id, but someone said it might be dangerous since it envolves all clusters.

[Sougata]

Yes, I agree with whoever has said FREE MEMORY without the id option can be dangerous i.e. it can lead to deleting the entire ABAP memory so any EXPORT command that has taken place internally (in the kernel) when your program is running will be lost forever.

You don't need to FREE local internal tables and CLEAR variables but at the end if you FREE and CLEAR the global internal tables and variables that should be the way to go. Like I said in my last post, it does not make sense to use FREE MEMORY statement if you are not using the ABAP memory to EXPORT or IMPORT data from your program.

Cheers,

Sougata.

[Former Member]

ok man. you answered my question about the impact involved by deleting all clusters. yes, the program uses several exports and imports in different points for particular data it handles and I can cont loose those...Thanks.