|
View previous topic :: View next topic
|
| Author |
Message |
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1325
Location: Vilnius, Lithuania
|
|
|
|
Allow defined allocate in AREA
You need an IBM ID to vote, should you be inclined to do so.
Description: Since many releases, Enterprise PL/I allows the allocation of defined amounts of heap using the "ALLOCATE" builtin, to quote the manual:
"ALLOCATE allocates storage of size n in heap storage and returns the pointer to the allocated storage."
It would be highly advantageous if this builtin function could be enhanced to allocate a defined (rounded to 8/16 bytes) number of bytes inside an AREA, while returning a pointer.
Use case: Parsing XML (and similar) documents frequently result in complex list or tree structures. Clearing up those structures does require a substantial amount of processing as each node needs to be FREE'd individually in the correct order to avoid memory leaks.
By building such lists and/or trees inside an AREA, removal of the entire list or tree is reduced to a single "AREA=EMPTY();" statement, which saves significant amounts of CPU time. |
|
| Back to top |
|
 |
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| And now? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| You click on the link if you think it is a good idea and add your support. It's a fairly recent feature, I think, to allow request for enhancements to be submitted across the web. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Memory leaks are as old as the world. If they are not solved now what the heck are we doing. Its getting some piece of memory and playing around with it. But if someone wants to allocate storage for every node in a list, its just freeing the memory in the right order. And there is a lot of memory management software build into operating systems. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1325
Location: Vilnius, Lithuania
|
|
|
|
| PeterHolland wrote: |
| Memory leaks are as old as the world. If they are not solved now what the heck are we doing. Its getting some piece of memory and playing around with it. But if someone wants to allocate storage for every node in a list, its just freeing the memory in the right order. And there is a lot of memory management software build into operating systems. |
The point is not freeing the memory, which is not very hard. The point is that freeing a tree with a few hundred nodes will take a considerable amount of time. Being able to wipe it out with a single instruction (which is in essence what an "AREA=EMPTY();" statement should generate under ideal circumstances will save a substantial amount of CPU time.
Here's a simple clean-up of a linked list:
| Code: |
2334.0 216 1 1 do cnty_ptr = cnty_top repeat nxt_ptr
2335.0 while(cnty_ptr ^= sysnull());
2336.0 217 1 2 nxt_ptr = cnty_nxt;
2337.0 218 1 2 free cnty_list;
2338.0 219 1 2 end; |
And this is the OPT(3) generated code:
| Code: |
0022B4 E310 D4DC 0214 002334 | LGF r1,<a1:d9436:l4>(,r13,9436)
0022BA E310 D4D8 0250 002334 | STY r1,<a1:d9432:l4>(,r13,9432)
0022C0 A7E9 0000 002334 | LGHI r14,H'0'
0022C4 E300 30E6 0080 002329 | NG r0,=X'00000000 0000007F'
0022CA E300 DB52 0272 002329 | STCY r0,<a1:d11090:l1>(,r13,11090)
0022D0 EC18 0005 007E 002334 | CIJE r1,H'0',@1L58
0022D6 002334 | @1L11391 DS 0H
0022D6 A7E9 0001 002334 | LGHI r14,H'1'
0022DA 002334 | @1L58 DS 0H
0022DA ECE8 0027 007E 002334 | CIJE r14,H'0',@1L60
0022E0 E300 1000 0014 002336 | LGF r0,_shadow16(,r1,0)
0022E6 E300 D660 0250 002336 | STY r0,<a1:d9824:l4>(,r13,9824)
0022EC E310 DE44 0550 002337 | STY r1,_temp28(,r13,24132)
0022F2 E54C D098 0040 002337 | MVHI #MX_TEMP1(r13,152),H'64'
0022F8 4110 D098 002337 | LA r1,#MX_TEMP1(,r13,152)
0022FC E3E0 DE44 0571 002337 | LAY r14,_temp28(,r13,24132)
002302 50E0 D09C 002337 | ST r14,#MX_TEMP1(,r13,156)
002306 E3F0 308E 0014 002337 | LGF r15,=V(IBMQPGDB)(,r3,142)
00230C 0DEF 002337 | BASR r14,r15
00230E A7E9 0000 002334 | LGHI r14,H'0'
002312 E310 D660 0214 002338 | LGF r1,<a1:d9824:l4>(,r13,9824)
002318 E310 D4D8 0250 002338 | STY r1,<a1:d9432:l4>(,r13,9432)
00231E EC18 FFDE 007E 002334 | CIJE r1,H'0',@1L58
002324 A7F4 FFD9 002334 | J @1L11391
002328 002338 | @1L60 DS 0H |
And for the AREA:
| Code: |
330.0
331.0 16 1 dcl a area (1200);
332.0 17 1 a = empty();
333.0
334.0 18 1 dcl i fixed bin (31); |
| Code: |
.AS 0000DE D70F D218 D218 000332 | XC A(16,r13,536),A(r13,536)
000777 0000E4 E3F0 300C 0014 000336 | LGF r15,=V(IBMQOFNT)(,r3,12) No, not this one!
000778 0000EA E54C D21C 0010 000332 | MVHI A(r13,540),H'16' |
A bit shorter and faster, I think... |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
