wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (12/22/88)
I'm working on a program that makes massive use of fonts. The problem
I have is that once a font is loaded into memory, it stays there forever.
I've tried other programs that use fonts and they also have the same
problem. The code is correct according to the RKM but I haven't been
able to get it to work.
.
.
textFont = OpenDiskFont(textAttr);
.
. code to use font
.
CloseFont(textFont);
Seemly the CloseFont() call dose not ever release the font from memory.
After using 20 fonts or so it is easy to lose over 100K of memory to dead
fonts hanging around. I'm trying to do real-time effects with Text so
I really need all the memory I can get. Dose anyone know what is wrong?
Wayne Knappandy@cbmvax.UUCP (Andy Finkel) (12/23/88)
In article <3599@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: >Seemly the CloseFont() call dose not ever release the font from memory. >After using 20 fonts or so it is easy to lose over 100K of memory to dead >fonts hanging around. I'm trying to do real-time effects with Text so >I really need all the memory I can get. Dose anyone know what is wrong? Like libraries and devices, fonts, once loaded hang around until the system requires more memory than is currently available. Then all fonts non in use get expunged. > Wayne Knapp -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
ewhac@well.UUCP (Leo L. Schwab) (12/23/88)
In article <3599@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: >I'm working on a program that makes massive use of fonts. The problem >I have is that once a font is loaded into memory, it stays there forever. >[ ... ] >Seemly the CloseFont() call dose not ever release the font from memory. >[ ... ] Dose [sic] anyone know what is wrong? > Nothing is wrong. Fonts are rather like libraries; they hang around in memory until memory becomes short. The reason it does this is so that it doesn't have to load them off disk every time they're opened. The fonts and libraries will be purged from memory when the memory is needed. You can force the system to purge all loaded fonts and libraries that are not currently in use by trying to allocate four gigabytes of RAM: AllocMem (4000000000L, NULL); This will always fail (unless you actually happen to *have* four gigabytes of RAM hanging around (or if AmigaDOS/Kickstart ever goes virtual)). However, in the process of trying to satisfy this request, Exec will make room in memory by flushing out all loaded fonts and libraries that aren't in use. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
ali@polya.Stanford.EDU (Ali T. Ozer) (12/23/88)
In article <10097@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > AllocMem (4000000000L, NULL); > > This will always fail (unless you actually happen to *have* four >gigabytes of RAM hanging around (or if AmigaDOS/Kickstart ever goes >virtual)). Just in case that request should succeed, you should do if (tmp = AllocMem(4000000000L, NULL)) FreeMem (tmp, NULL) Otherwise you've just blasted away 4 gigabytes of memory without giving it back. Tsk, tsk, Leo. 8-) While you're dreaming, you might as well do it all the way! Ali Ozer, aozer@NeXT.com
ewhac@well.UUCP (Leo L. Schwab) (12/25/88)
In article <5783@polya.Stanford.EDU> aozer@NeXT.com (Ali Ozer) writes: >In article <10097@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> AllocMem (4000000000L, NULL); >> >> This will always fail [ ... ] > >Just in case that request should succeed, you should do > > if (tmp = AllocMem(4000000000L, NULL)) FreeMem (tmp, NULL) > >While you're dreaming, you might as well do it all the way! May as well do it right, too: if (tmp = AllocMem (4000000000L, NULL)) { puts ("Don't worry, you have *plenty* of memory."); FreeMem (tmp, 4000000000L); } /* You forgot ^^^^^^^^^^^ that */ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jamiep@ncoast.UUCP (Jamie Purdon) (12/29/88)
and libraries when a "larger than available" amount of memory is requested. PROBLEM: The printer.device gets "flushed" "too often" when this "huge alloc" method is used. This forces the floppy-based user to keep re-inserting the Workbench disk, since devices are flushed as well as fonts. SUGGESTION: Do (2) "huge alloc"s. The first one would ask for "a large amount" (>1mb) of CHIP memory. After this first Alloc, see if you have (can allocate) the desired hunk. Then, (only after clearing out CHIP,) go ahead with a "huge alloc" of FAST memory. This method will "un-frag" memory without clobbering all of it needlessly. Jamie Purdon
mp1u+@andrew.cmu.edu (Michael Portuesi) (12/30/88)
ewhac@well.UUCP (Leo L. Schwab) writes: > You can force the system to purge all loaded fonts and libraries > that are not currently in use by trying to allocate four gigabytes of RAM: > > AllocMem (4000000000L, NULL); > > This will always fail (unless you actually happen to *have* four > gigabytes of RAM hanging around (or if AmigaDOS/Kickstart ever goes > virtual)). Which sounds to me like a good reason you might not want to pull such a trick -- if Amigos (how's that for a name for the Amiga operating system) ever does go virtual, the call might actually succeed. You might want to put in a sanity check so that if the call *does* succeed, the memory is deallocated. Perhaps better would be an Exec call to automatically flush non-used libraries and fonts from memory. Does one exist? Is it a good idea for random programs to be flushing things that might be better off cached? --M -- Michael Portuesi / Information Technology Center / Carnegie Mellon University INET: mp1u+@andrew.cmu.edu / BITNET: mp1u+%andrew.cmu.edu@cmccvb UUCP: ...harvard!andrew.cmu.edu!mp1u+ "I'm very sorry, Master, but that WAS the backup system" -- Slave
papa@pollux.usc.edu (Marco Papa) (12/30/88)
In article <YXienJy00Vsf0AHTAo@andrew.cmu.edu| mp1u+@andrew.cmu.edu (Michael Portuesi) writes: |ewhac@well.UUCP (Leo L. Schwab) writes: || You can force the system to purge all loaded fonts and libraries || that are not currently in use by trying to allocate four gigabytes of RAM: || AllocMem (4000000000L, NULL); || This will always fail (unless you actually happen to *have* four || gigabytes of RAM hanging around (or if AmigaDOS/Kickstart ever goes || virtual)). |Perhaps better would be an Exec call to automatically flush non-used |libraries and fonts from memory. Does one exist? ^^^^^^^^^^^^^^ Nope. |Is it a good idea for random programs to be flushing things that might be | better off cached? Well, I can tell you that the practice Leo refers to is widely used since it is the ONLY way to flush things and force memmory merge. I use it myself. The performance penalty is in my opinion not that big. An Exec call that ASKED for a flush would be nice, though. (1.4? Dale?, Jimm?). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jimm@amiga.UUCP (Jim Mackraz) (12/31/88)
In article <14355@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: )In article <YXienJy00Vsf0AHTAo@andrew.cmu.edu| mp1u+@andrew.cmu.edu (Michael Portuesi) writes: )|ewhac@well.UUCP (Leo L. Schwab) writes: )|| You can force the system to purge all loaded fonts and libraries )|| that are not currently in use by trying to allocate four gigabytes of RAM: )|| AllocMem (4000000000L, NULL); )|| This will always fail (unless you actually happen to *have* four )|| gigabytes of RAM hanging around (or if AmigaDOS/Kickstart ever goes )|| virtual)). )|Perhaps better would be an Exec call to automatically flush non-used )|libraries and fonts from memory. Does one exist? ) ^^^^^^^^^^^^^^ )Nope. ) )|Is it a good idea for random programs to be flushing things that might be )| better off cached? ) )Well, I can tell you that the practice Leo refers to is widely used since it )is the ONLY way to flush things and force memmory merge. I use it myself. )The performance penalty is in my opinion not that big. An Exec call that )ASKED for a flush would be nice, though. (1.4? Dale?, Jimm?). ) )-- Marco Papa 'Doc' Hold on, here, fellas. Is there a real reason to flush the font? This thread started when some guy thought the memory for an unused font was unavailable. It's not unavailable, it's just unpurged. If you NEED the memory, won't you get it when you try to allocate it? If you need a large chunk of memory, won't an expunge happen when you try to get it? This isn't so that your customers feel that you've returned all your memory, is it? Or maybe to satisfy the BKDC rules or something. We've identified some problems in the Expunge processing, but you are going against the general principle. Ask for what you need. The system should expunge things if necessary to satisfy your requests. Problems I'm aware of include: 1) Expunge should walk the device/libs lists in reverse order so that if one library is opened by another, the opener hears the expunge first. (discovered by Bill Hawes, the little genius). 2) Expunging should terminate when it gets enough memory for the AllocMem. 3) Some device (serial maybe) hangs onto resources until it is expunged, so expunging it is the only way to get the resources back (this would be a bug in the device). If you want to check your memory usage, select 'flushlibs' from the secret WB menu (LoadWB -debug), don't put a gratuitous huge allocation in your program. The whole point is to NOT expunge things unless the memory is really needed. If I'm missing something here, I'd be pleased to be educated. jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are not to be taken as Commodore official policy.
papa@pollux.usc.edu (Marco Papa) (12/31/88)
In article <3226@amiga.UUCP| jimm@cloyd.UUCP (Jim Mackraz) writes: |In article <14355@oberon.USC.EDU| papa@pollux.usc.edu (Marco Papa) writes: [initial thread deleted] |)Well, I can tell you that the practice Leo refers to is widely used since it |)is the ONLY way to flush things and force memmory merge. I use it myself. |Hold on, here, fellas. Is there a real reason to flush the font? This thread |started when some guy thought the memory for an unused font was unavailable. |This isn't so that your customers feel that you've returned all your memory, |is it? Or maybe to satisfy the BKDC rules or something. That's definitely THE main reason most third parties do the HUGE AllocMem, as the last thing before closing shop. |We've identified some problems in the Expunge processing, but you are going against |the general principle. Ask for what you need. The system should expunge |things if necessary to satisfy your requests. | |Problems I'm aware of include: |1) Expunge should walk the device/libs lists in reverse order so that if one | library is opened by another, the opener hears the expunge first. | (discovered by Bill Hawes, the little genius). |2) Expunging should terminate when it gets enough memory for the AllocMem. |3) Some device (serial maybe) hangs onto resources until it is expunged, so | expunging it is the only way to get the resources back (this would be a | bug in the device). Are these bugs still present in 1.3? In they are, why weren't fixes included in SetPatch if, as it seems from your comments, these are all known bugs? |If I'm missing something here, I'd be pleased to be educated. No, you're not missing anything. Bu from now on consider that, as I said, the practice is widespread. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ewhac@well.UUCP (Leo L. Schwab) (01/02/89)
In article <14370@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <3226@amiga.UUCP| jimm@cloyd.UUCP (Jim Mackraz) writes: >|Hold on, here, fellas. Is there a real reason to flush the font? This thread >|started when some guy thought the memory for an unused font was unavailable. > >|This isn't so that your customers feel that you've returned all your memory, >|is it? Or maybe to satisfy the BKDC rules or something. > >That's definitely THE main reason most third parties do the HUGE AllocMem, >as the last thing before closing shop. > Well, *I* never do that. I suspect it's done by developers to see if their code returned all the memory it allocted properly. Checking to see if everything get returned can be a bit of a pain, particularly if you're working out of VD0: (which is not to slander VD0:). My test cycle is: avail, <program>, avail. If the program opened previously unopened libraries, then I do another <program>,avail cycle and check the numbers. In VD0:, this can be a problem, because it likes to free up memory "every so often". Thus, I often find myself saying "dir >NIL: : OPT A" to try and make it happen more often so that the avail numbers don't say I have more free memory that I started with. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jimm@amiga.UUCP (Jim Mackraz) (01/03/89)
In article <14370@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: )In article <3226@amiga.UUCP| jimm@cloyd.UUCP (Jim Mackraz) writes: )|Hold on, here, fellas. Is there a real reason to flush the font? This thread )|started when some guy thought the memory for an unused font was unavailable. )|This isn't so that your customers feel that you've returned all your memory, )|is it? Or maybe to satisfy the BKDC rules or something. )That's definitely THE main reason most third parties do the HUGE AllocMem, )as the last thing before closing shop. Then we have identified a Point of Education. Maybe something like 'flushlibs' should be included in a standard Workbench menu (and in System: ?) so that we can cater to people's psychological problems. ;^) At very least, amend the BKDC rules to say that you must return memory after a manual purge is run. )|Problems I'm aware of include: )|1) Expunge should walk the device/libs lists in reverse order so that if one )| library is opened by another, the opener hears the expunge first. )| (discovered by Bill Hawes, the little genius). )|2) Expunging should terminate when it gets enough memory for the AllocMem. )|3) Some device (serial maybe) hangs onto resources until it is expunged, so )| expunging it is the only way to get the resources back (this would be a )| bug in the device). )Are these bugs still present in 1.3? In they are, why weren't fixes included )in SetPatch if, as it seems from your comments, these are all known bugs? Come again, Marco? All known bugs must be fixed in 1.3 or SetPatch? That's not realistic, and it makes me disinclined to mention known problems even in this developer-oriented forum. I learned most of these on BIX, myself. No, all of them. See you there. )|If I'm missing something here, I'd be pleased to be educated. )No, you're not missing anything. Bu from now on consider that, as I said, the )practice is widespread. Well, we've identified that *someone* needs education, and I suppose that includes the users. I'll forward the suggestion to cbmvax!bugs, with the words "Enhancement" and "documentation" in the subject line. )-- Marco Papa 'Doc' jimm
papa@pollux.usc.edu (Marco Papa) (01/03/89)
In article <3230@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >)|This isn't so that your customers feel that you've returned all your memory, >)|is it? Or maybe to satisfy the BKDC rules or something. > >)That's definitely THE main reason most third parties do the HUGE AllocMem, >)as the last thing before closing shop. > >Then we have identified a Point of Education. Maybe something like 'flushlibs' >should be included in a standard Workbench menu (and in System: ?) so that >we can cater to people's psychological problems. ;^) Fine on BOTH. Believe it or not, there are people that WON"t buy a piece of software, if if doesn't SHOW that it returns ALL the memory. Some of the reviewers are even worse, and you know that products get easily killed by one or two bad reviews. Note that the documentation that comes from CBM and most third parties doesn not mention anything about the fact that some stuff (libarries/devices/etc..) stays resident unless not used and the space is needed. For myself, for the next version of A-Talk III I have taken out the HUGE AllocMem and will furnish the "flushlibs" program on the disk, document it for users and reviewers that want to check that we do return all memory and give ample WARNINg that the system might be "flaky" afterwards. Gee, I still recall the 238 bytes that I was not freeing for which I was not sleeping at night :-) and that I tracked down only with the help of our "great" Bill Hawes (thanks Bill). >)Are these bugs still present in 1.3? In they are, why weren't fixes included >)in SetPatch if, as it seems from your comments, these are all known bugs? > >Come again, Marco? All known bugs must be fixed in 1.3 or SetPatch? >That's not realistic, and it makes me disinclined to mention known problems >even in this developer-oriented forum. I learned most of these on BIX, myself. >No, all of them. See you there. Sincerely, I had not seen them in any of the BETA/GAMMA docs or on BIX. I would have "behaved" otherwise (I mean, take the AllocMem out) if I had known of the possible consequences. I know other developers are in the same situation. Anyway, you're right, the subject is really not for Usenet. See you on BIX. >Well, we've identified that *someone* needs education, and I suppose that >includes the users. I'll forward the suggestion to cbmvax!bugs, with >the words "Enhancement" and "documentation" in the subject line. Good idea. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
paolucci@snll-arpagw.UUCP (Sam Paolucci) (01/03/89)
In article <10191@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
-> Checking to see if everything get returned can be a bit of a pain,
->particularly if you're working out of VD0: (which is not to slander VD0:).
->My test cycle is: avail, <program>, avail. If the program opened
->previously unopened libraries, then I do another <program>,avail cycle and
->check the numbers. In VD0:, this can be a problem, because it likes to free
->up memory "every so often". Thus, I often find myself saying "dir >NIL: :
->OPT A" to try and make it happen more often so that the avail numbers don't
->say I have more free memory that I started with.
Doesn't memory get freed if you run CleanRamDisk? I believe that this
program was provided with VD0: specifically for the purpose of freeing
up the memory.
->Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.gov