/me notes that he doesn't want anyone accessing his memory.
psstt... I'm very scared. I think the new automated poll code reads the chatterbox. People were just discussing this tonight (I believe before the poll came up.). We were talking about perl 6 and all that. /me drops subject and goes off to write the Brain::Memory module, including of course, the putToSleep() and killCells() methods.
Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.
The problem with beer management is that your memory
decreases, and you need to reboot quite often.
But hey, I also allows you to forget things you would like to forget.
Dr. Mark Ceulemans
Senior Consultant IT Masters, Belgium
I forget way more than I should. My brain is entirely too ineffecient at memory management and I would love to let Perl do it. Perl is pretty good at memory management.
The problem lies in my software to wetware interface. Try as I might, I just haven't been able to get it right. I thought that sending the delta and gamma waves towards my head would suffice. The taint checks are working fine but if an alpha wave gets through Perl coredumps. :( Perhaps if I use an EEG, I would have better results...
Beer, of course, especially anything from Stone Brewery. One greases the wheels for more relaxed coding (although not at the office). Two or more means it's time to walk away from the keyboard and watch football.
My current preferred method is lazy heap management. Information is kept intact (even when it's not referenced) until it is absolutely necessary to reuse the memory for something else. In the event that the information is requested again and the memory has not been overwritten, reclamation is swifter.
Coincidentally, this is similar to how the Solaris kernel manages buffer cache memory pages. (And also pages stolen from an active process.) These pages are placed on a special "free list" (called the cache list) and will only be utilized when the traditional free list is empty.
As a human, I've also adopted this strategy with respect to reclamation of disk space. Even though I know something is no longer in use, I keep it around on the chance that it might be useful for something later. When space is at a premium, I can then use some procedure for cleaning out old stuff.
Does this lead to chaos? You bet. But with a good search engine and clever indexing, I can find my way through the uproar to the information that interests me.
Now, if only I can get the screaming in my head to stop!
...All the world looks like -well- all the world,
when your hammer is Perl.
If my memory serves me correctly (which it most likely is not), then memory is a good thing only if you have a lot of it. If you've only got a little bit of memory, you've probably got a peanut problem :)
reference counting is useless in any reasonably sized OO perl app where the app is persistent (eg: mod_perl). having to manually break circular references to prevent memory leaks is naff. i may as well write in C++. bring on proper GC!
GC does not necessarily provide automatic circular reference breaking.
I prefer GC over reference counting because it simplifies implementation. A simpler implementation contains fewer bugs (on average). One improperly accounted reference can bring Perl down with a core dump, or worse.