Article View: comp.lang.clos
Article #336How to neatly destroy instances?
From: miller
Date: Wed, 14 Oct 1992 19:58
Date: Wed, 14 Oct 1992 19:58
17 lines
1391 bytes
1391 bytes
> Date: Wed, 14 Oct 92 12:14:03 PDT > From: jonl%kuwait@lucid.com (Jon L White) > But that's the beauty of "generational" style collectors! You're right; I recant (or recast) my position vis: "Always cheaper"; I had in mind only large structures, such as (most... in my applications) CLOS instances, that are relatively long-lived, not basic cons cells. Clearly generational scavanging is a big win in the latter case. I think it is intuitively obvious that for most such structures the application is in a far better position to know when the structure will be of no further use. A substantial portion of the time to GC isn't sticking cons cells back on the free list, but deciding which ones need to be so stuck. So I still claim having an explicit free (or at least some amount of low-level control on memory allocation, WHEN NEEDED AND APPROPRIATE) would be 'a good thing'.
Technical Details
Message-ID:
<9210141958.AA09948@alabaster.cs.rochester.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!cs.rochester.edu!millerReferences:
<9210141914.AA10118@kuwait.lucid>Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.clos Path: arc1-ca.pugleaf.net!sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!cs.rochester.edu!miller From: miller@cs.rochester.edu Subject: How to neatly destroy instances? Message-ID: <9210141958.AA09948@alabaster.cs.rochester.edu> Sender: daemon@cis.ohio-state.edu Organization: The Ohio State University Department of Computer and Information Science References: <9210141914.AA10118@kuwait.lucid> Date: Wed, 14 Oct 1992 19:58:25 GMT Lines: 18