for "garbage" and "collection" and "1981"
Search term: garbage;collection;1981
No spelling errors allowed, case-insensitive, partial words match.
Information on how to form queries.
@TechReport{Lieberman80b,
author = "H. Lieberman and Carl E. Hewitt",
title = "A Real Time Garbage Collector That Can Recover
Temporary Storage Quickly",
institution = "Massachusetts Institute of Technology, A.I. Lab.",
address = "Cambridge, Massachusetts",
type = "Technical Report",
number = "A. I. MEMO 569",
keywords = "Real Time Garbage Collection, Reference Counting,
LISP, Object-Oriented Programming, Virtual Memory,
Parallel Processing",
cite = "\bibitem{LH83a} (\cite{LH83c})",
note = "siehe auch A. I. MEMO 569A, 1983 und 569A, Okt. 1981",
month = apr,
year = "1980",
}
@TechReport{Lieberman81c,
author = "Henry Lieberman and Carl E. Hewitt",
title = "A Real Time Garbage Collector Based on the Lifetimes
of Objects",
institution = "Massachusetts Institute of Technology, A.I. Lab.",
address = "Cambridge, Massachusetts",
type = "Report",
number = "A. I. MEMO 569A",
keywords = "Real Time Garbage Collection, Reference Counting,
LISP, Object-Oriented Programming, Virtual Memory,
Parallel Processing",
cite = "\bibitem{LH83a} (\cite{LH83c})",
note = "siehe auch A. I. MEMO 569A, 1983",
month = oct,
year = "1981",
}
@TechReport{Ae:ISWGC,
author = "J. P. H. Aerts",
title = "Implementing {SASL} without Garbage Collection",
institution = "Eindhoven University of Technology",
address = "The Netherlands",
type = "EUT Report",
number = "81--WSK--05",
year = "1981",
}
@PhdThesis{DionJeremy:phd,
title = "Reliable Storage in a local Network",
author = "Jeremy Dion",
school = "University of Cambridge",
year = "1981",
month = feb,
abstract = "This thesis discusses the problems involved in
designing a file server to provide storage in a local
network. It is based on experience gained from the
design and implementation of a file server for the
Cambridge ring.",
keyword = "CFS, DFS, Cambridge file server, FS, universal
distributed file server CAP, index files, atomic files,
garbage collection, disks reliability, crash recovery,
disk layout, multi-site atomic transactions",
}
@Article{Kurokawa:spe:1981,
author = "Toshiaki Kurokawa",
title = "A New Fast and Safe Marking Algorithm",
journal = "Software -- Practice and Experience",
volume = "11",
number = "6",
pages = "671--682",
month = jul,
year = "1981",
refs = "9",
checked = "19940428",
keywords = "marking algorithm, garbage collection, LISP stacked
node checking method",
abstract = "A new marking algorithm for garbage collection is
presented. Although the method is a variation of the
usual simple stacking algorithm, in practice this
algorithm has quite improved both in stack space and
processing time. One significant modification is to
stack a node only when both the sublists are unmarked.
The other innovation is a ``stacked-node-checking''
method invoked after each stack-overflow. With this
method, a number of unnecessary nodes are eliminated,
the stack is compacted, and the marking process can
resume using the generated space in the stack. This
algorithm has been used for LISP1.9 garbage collection
for years, and succeeded in showing good figures.",
}
@InProceedings{owicki:81,
title = "Making the World Safe for Garbage Collection",
author = "Susan Owicki",
pages = "77--86",
booktitle = "Conference Record of the Eighth Annual ACM Symposium
on Principles of Programming Languages",
address = "Williamsburg, Virginia",
year = "1981",
month = jan,
}
@InProceedings{Svobod81,
author = "L. Svobodova",
title = "A Reliable Object-Oriented Repository for a
Distributed Computer System",
booktitle = "Proceedings of the Eight Symposium on Operating
Systems Principles",
pages = "47--58",
month = "[12]",
year = "1981",
keywords = "Transactions File System Optical Discs",
abstract = "The repository described in this paper is a component
of a distributed data storage system for a network of
many autonomous machines that might run diverse
applications. The repository is a server machine that
provides very large, very reliable long-term storage
for both private and shared data objects. The
repository can handle both very small and very large
data objects, and it supports atomic update of groups
of objects that might be distributed over several
repositories. Each object is represented as a history
of its states; in the actual implementation, an object
is a list of immutable versions. The core of the
repository is stable append-only storage called
Version-Storage (VS). VS contains the histories of all
data objects in the repository as well as information
needed for crash recovery. To maintain the current
versions of objects online, a copying scheme was
adopted that resembles techniques of real-time garbage
collection. VS can be implemented with optical disks.",
note = "Published as Proceedings of the Eight Symposium on
Operating Systems Principles, volume 15, number 5",
}
@Article{Grit81,
author = "D. H. Grit and R. L. Page",
title = "Deleting irrelevant tasks in an expression oriented
multiprocessor system",
journal = "ACM Trans. Prog. Lang. and Sys.",
volume = "3",
number = "1",
pages = "49--59",
month = jan,
year = "1981",
keywords = "multiprocessor kill garbage collection applicative
functional recursive GC recursion termination",
}
@Article{Grit81,
author = "D. H. Grit and R. L. Page",
title = "Deleting Irrelevant Tasks in an Expression-Oriented
Multi-Processor System",
journal = "ACM Transactions on Programming Languages and
Systems",
volume = "3",
number = "1",
year = "1981",
keywords = "multiprocessor garbage collection functional",
}
@Article{Cohen:1981:GCL,
author = "Jacques Cohen",
title = "Garbage Collection of Linked Data Structures",
journal = "ACM Computing Surveys",
volume = "13",
number = "3",
pages = "341--367",
month = sep,
year = "1981",
acknowledgement = "Nelson H. F. Beebe, Center for Scientific
Computing, Department of Mathematics, University of
Utah, Salt Lake City, UT 84112, USA, Tel: +1 801 581
5254, FAX: +1 801 581 4148, e-mail:
\path|beebe@math.utah.edu|",
bibdate = "Sat Sep 24 22:18:11 1994",
}
Found 10 references in 8 bibliographies.
You used 19 seconds of our CPU time.