Garbage collection

From Ninerpedia
Revision as of 13:01, 5 January 2015 by Stephen Shaw (talk | contribs) (add link to ExBas)
Jump to navigation Jump to search

From time to time you may notice your sprites freeze for a moment or a musical note sound just a little longer than it should. This is due to the computer having a clearout of redundant variables, making room for more. This is called Garbage Collection. In Extended BASIC you can take charge of this fairly random behaviour.

For this you need Extended Basic and expansion memory.

One of the things Myarc intended to include in their XB was a forced garbage collection, but they seem to have run out of room.

It is really quite easy, but what is it?

Type in this program and run it:

100 CALL CLEAR 
110 A$="1234567890" 
120 FOR T=1 TO 12 
130 CALL SPRITE (#T,42,2,30+T*3,30+T*3,0,34+T) 
140 NEXT T 
150 CALL PEEK(-31890,I,H) 
160 CALL PEEK(-31974,H,L) 
170 A$=A$&A$&A$&A$ 
180 DISPLAY AT(20,15): "FREE:" 
190 F=(H*256+L)-(I*256+M) 
200 DISPLAY AT(21,15):F 
210 GOTO 140 
220 END 

The number you see counting down is the free stack space- it is being filled with redundant definitions of A$ (line 170). When the number reaches/passes zero, you will see that it starts again from a high value- but at the moment of changeover, all your sprites will halt briefly.

During this brief halt, the computer is checking the stack to see what information there is redundant (no longer required) and getting rid of anything it doesn't need- garbage collection.

Garbage collection not only causes sprites to halt but can also interfere with music, causing the odd note to sound for longer. Instead of having garbage collection occur when the stack is full - which can be quite often if the program is long and stack space short- it can be useful to force a garbage collection at a time we choose, when the effect may not be too obvious. Also, if we do a garbage collection before the stack is full, the pause may be quite a bit shorter.

Here's how to do it... insert the following lines into the above program:

95 CALL INIT 
205 CALL LOAD(-31885,144,"",-31858,81,169,152,0) 

Now run the program again. Notice that the stack space remains constant, as we are forcing a garbage collection after each definition of A$. How is sprite speed affected?

Try garbage collection at an intermediate stage

204 IF F>10000 THEN 210 

Any difference? Have fun.

Thanks to the Sydney User Group (TIsHUG) in Australia for this one, taken from their newsletters for March and July 1987.