What Ive done in the past is Allocate and reuse chunks 0-32KB,32KB- 64 KB, 64KB-128KB if req < 32KB then use p32KBblock else if req < 64LB then use p64kbBlock else if req < 128KB then use p128KBblock
else /* request is over 128KB *. Allocate it ... Afterwards if req > 128KB then free block. If you need multiple blocks create a quick cell... do not free a block... just chain it to the free chain for that block size. please feel free to contact me offline for more info Colin On Wed, 8 Mar 2023 at 19:06, Mike Schwab <mike.a.sch...@gmail.com> wrote: > Well, the obvious solution is to always allocate an area for the > maximum size. For small items use parts of one or more large areas, > for large items use and release a separate area. > > On Wed, Mar 8, 2023 at 8:04 AM Massimo Biancucci <mad4...@gmail.com> > wrote: > > > > Hi, > > > > my LE options include RPTSTG and the output confirmed to me there are no > > issues with ALLOCATE and FREE. > > > > About the app itself, it's a monitor who receives a bunch of data into a > > buffer from Db2 and spreads items into lots of single varying length > chunks > > within a tree. > > The varying length (from few bytes to KBs) is the main reason because I > > don't use an array. The time I wrote the application seemed to be a good > > way to avoid memory waste. > > At every iteration info about single nodes can be still present or not. > If > > yes, I have to refresh data, if not I've to logically delete the node. > > From time to time a garbage collector releases the useless nodes. > > > > The main problem is the communication buffer that DB2 sometimes asks me > to > > increase (even if it's really huge, more than 100MB and I can't know the > > maximum needed size). > > These big chunks tend to fill the memory with a lot of wasted space. > > Probably I have to rethink the way I allocate and free such a buffer. > > I read about the AREA and it seems to me it's not the right tool for it. > > > > Regards. > > Max > > > > > > > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > Privo > > di virus.www.avast.com > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > Il giorno mer 8 mar 2023 alle ore 13:52 Steve Smith <sasd...@gmail.com> > ha > > scritto: > > > > > Have you looked at the documentation for RPTSTG? Have you tried the > > > process described? > > > > > > sas > > > > > > > > > On Wed, Mar 8, 2023 at 5:31 AM Massimo Biancucci <mad4...@gmail.com> > > > wrote: > > > > > > > Thanks to everybody for your support. > > > > As usual I learnt a lot. > > > > > > > > The problem was (as usual business) between my seat and my keyboard. > > > > The PLI FREE statement was not consistent with ALLOCATE. The size of > the > > > > area to be free was not correct. > > > > I thought it was not so important and I was wrong. The manual states > it > > > > counts. > > > > > > > > Anyway my program suffers of HEAP fragmentation because of a mix of > (lot) > > > > small areas that I often need to allocate and free and (few) big > areas > > > that > > > > I need to free and allocate rarely (root cause of the problem). > > > > To trigger the issue I ran the program with a small region size, > > > hopefully > > > > with a bigger region I'll run ok. > > > > It seems there's no way to ask PLI/LE for heap defrag. > > > > > > > > Best regards. > > > > Max. > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
