At the moment I only look at one HANC (heap segment),
which is of limited size, depending on the HEAP parameters
on enclave startup. Typical size is from some KB to some MB.
For example, today I tested with 64 KB heap segment size,
which is pretty small.
That is, if you allocate several small areas which take (much) less than
64 KB, all is fine, and you will get a significant delta listing. Today,
there
were only 11 areas of (in sum) 600 bytes, which were not freed on
the interesting function call. (This could anyway be a problem, if this
function
is called several million times per day in an online environment; in
fact it is
a function that gets a customer address from the DB2 database).
If a new heap segment is started between two calls, the delta listing
(as it is implemented at the moment) will look not so good. You can control
this by defining larger segment sizes.
Because the snapshot and the delta listing is limited to one HANC, it is
pretty fast.
You can take a snapshot of the whole heap chain, but there is no
delta listing of the whole heap chain at the moment. The delta listing
of the actual HANC seemed sufficient on the first shot.
Other parameters of the heap snapshot function are:
- which file handle for output? Default is stderr
- do you want size summary or not? (number of occupied and free areas,
total size)
- which size of every occupied area do you want to be dumped
(nothing at all, only the address and the length, or the first n bytes)?
- only the actual HANC or the whole heap chain?
- simple hex dump of the HANCs as a whole, or edited HANC (header info
with field names, individual areas and so on)
The implementation of the LE heap seems to be pretty stable over time;
the documentation is from 1997 and 2005, and the information is still
valid;
so I guess there will be not much changes in the future. The algorithm is
from IBM Watson Research Center, see the presentation below.
Kind regards
Bernd
David Crayford schrieb:
Cool! So you run the heap control blocks and take snapshots? Does that
work well when lots of memory is being allocated?
On 9/08/2016 9:16 PM, [email protected] wrote:
No, I don't instrument at all.
I use my knowledge of the LE heap implementation (see the presentation
mentioned below) to store a map of all allocated and free areas at a
given time
(area adresses and lengths) and then - some microseconds later - I
compare that
with the new image then. Then I build a delta listing which shows all
the areas
that have changed in the meantime, that is, which have been allocated
and not freed.
If you call this before and after a critical function, you will see
exactly
what areas are left "unfreed" by this function. This proved to be very
helpful in our environment, especially if the critical function is
written
by another team. (I don't need to "instrument" the functions of the
foreign team).
Kind regards
Bernd
-----Original-Nachricht-----
Betreff: Re: COBOL 2014 dynamic capacity tables
Datum: 2016-08-09T13:53:15+0200
Von: "David Crayford" <[email protected]>
An: "[email protected]" <[email protected]>
I use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory
leaks. How is your instrumentation different? I assume you wrap
malloc()/free() calls?
On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:
IMO there is no need to create additional heaps
to support dynamic tables in COBOL.
I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something like "Stacks are easy,
heaps are fun"). There are COBOL examples included, which
use the LE functions CEEGTST (get storage) and CEEFRST
(free storage) - I hope, I recall the names correctly.
Based on these functions (which are malloc and free, after all),
you could do all sorts of dynamic allocations from COBOL, using
the normal LE "user heap", which is sufficient, IMO.
BTW: I wrote some functions in the last few days, which dumps all
the allocated heap areas and - more interesting - they write reports,
how the heap has changed since the last call. This is very interesting
...
if you have a function that you think that does not free its heap areas
properly, you can call this heap report function before and after
this function call and find out by looking at the so called heap delta
listing.
If you are interested, feel free to contact me offline.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
