GC, memory inspector, memory consumption

[Former Member]

Hello,

I have a question regarding the GC on the one hand and the information provided by the memory inspector on the other. Please consider the following simple code snipplet of some method

METHOD test_mem.

  DATA: mem_test_obj TYPE REF TO zcl_anything.

  cl_abap_memory_utilities=>do_garbage_collection( ).         "tabula rasa
  cl_abap_memory_utilities=>write_memory_consumption_file( ).

  DO 100 TIMES.
    CREATE OBJECT mem_test_obj. "say each instance requires 100KB of bound memory
  ENDDO.

  cl_abap_memory_utilities=>write_memory_consumption_file( ). "second snapshot
  
  cl_abap_memory_utilities=>do_garbage_collection( ).
  cl_abap_memory_utilities=>write_memory_consumption_file( ). "third snapshot

ENDMETHOD. 

I'd expect the mem inspector to show 100 instances of ZCL_ANYTHING in the second memory snapshot with a total amount of 10 MB bound memory. In the third snapshot I would expect to see one instance with 100KB of bound memory as the GC should have collected the 99 unreachable handles/instances created in the DO loop (provided there has not been a GC run inbetween triggered elsewhere) .

However, the mem inspector only displays one instance (and only the pertaining 100KB of memory) in the second snapshot; can someone explain?

Furthermore, can someone with knowledge of the ABAP VM comment on the general costs of creating objects (empty constructor) with regard to memory(-overhead) and runtime performance? What happens (conceptionally) within the AVM when a CREATE OBJECT statement is processed? So far I have been reluctant to create "too many" objects (say while iterating over a large itab) but after some measurements it looks like the creation process as such is really fast.

Regards,

Sebastian Kamp

P.S. Please don't discuss the general OO pros and cons of creating objects and throwing them away, this is a different topic..

[MarcinPciak]

I'd expect the mem inspector to show 100 instances of ZCL_ANYTHING in the second memory snapshot with a total amount of 10 MB bound memory. In the third snapshot I would expect to see one instance with 100KB of bound memory as the GC should have collected the 99 unreachable handles/instances created in the DO loop (provided there has not been a GC run inbetween triggered elsewhere) .

You are using only one object reference which you constantly reinitiate. So the memory inspector only eveluates this last object which (after do loop) reside in memory. I think you should have a collection of these objects in order to eveluate them all.

DATA: lt_mem_test_obj TYPE TABLE OF REF TO zcl_anything.
FIELD-SYMBOLS <line> TYPE REF TO zcl_anything.

do 100 times.
    APPEND INITIAL LINE TO lt_mem_test_obj ASSIGNING <line>.
   CREATE OBJECT <line>.
enddo.

Regards

Marcin

[Former Member]

Hello Marcin,

thanks for you answer.

You are using only one object reference which you constantly reinitiate.

Well, that was kind of the point I was trying to discuss. If we would store the references each in an itab of course the GC would not clean them up.

I mean the reason of having a GC is to clean up all the unreachable references automatically (or on demand), so I was trying to construct an example where a lot of objects are unreachable as the only reference to them gets lost (by reusing the same handle).

So the memory inspector only eveluates this last object which (after do loop) reside in memory.

That is imo the key question; is there only this one last object which resides in memory ( before a GC run) - only because the other references get lost? So far I thought this was just the requirement for getting freed by the GC!

Regards,

Sebastian

[alex_campbell]

I was always under the impression that garbage collection was automatic. By that I mean as soon as you execute a statement which removes the last reference to an object, that object is deleted immediately. In your case, each object would be deleted from memory as soon as the refernce variable was assigned to a new object.

I'm still not an expert with ABAP OO so I could be completely wrong. If my statement is incorrect someone plese correct me.

[Sandra_Rossi]

Hi Sebastian,

I think it costs nothing to the system to reuse immediately the space, so the garbage collector is probably not used. Did you have a look at these notes which explain some principles of the Garbage Collector? Note 580871 - Calling the Garbage Collector explicitly; Note 628303 - Heuristic for calling the garbage collector;

Sandra

[Former Member]

Thanks all for your input.

I think I can answer the first question myself. In the debugger in the New Tools menu under Special Tools->System Areas I found some interesting information. In the area(?) OBJMGR you can monitor the current state of the GC.

For the example I have provided - when you remove the write_mem_consumption_file() calls - one can see that the figures

- Current alloc. obj. space

- No of allocations since last GC

- Current space for O&Ds

grow indeed with each interation until a GC run is triggered (explicitly or when one of the thresholds is reached).

Now, what you can also see is that with each writing of a memory snapshot a GC run is triggered automatically! So no wonder the memory inspector always lists a single instance only => a memory snapshot always displays the state directly after a GC clean up. (AVM experts: please confirm!)

Remains the second question - cost of object creation - to be answered

Regards,

Sebastian

[SuhaSaha]

Hello Seb,

That was indeed a very good piece of information, thanks! Are there any client params which set these threshold values?

Cheers,

Suhas

[Former Member]

Hello Suhas,

not that I am aware of (I'll check with the Basis guys ;-). The notes Sandra provided contain some info though what these thresholds mean in terms of GC heuristic.

Regards, Sebastian