Conference Paper

Understanding memory allocation of scheme programs

DOI: 10.1145/357766.351264 Conference: Proceedings of the fifth ACM SIGPLAN international conference on Functional programming, Volume: 35
Source: DBLP


Memory is the performance bottleneck of modern architectures. Keeping memory consumption as low as possible enables fast and unobtrusive applications. But it is not easy to estimate the memory use of programs implemented in functional languages, due to both the complex translations of some high level constructs, and the use of automatic memory managers.To help understand memory allocation behavior of Scheme programs, we have designed two complementary tools. The first one reports on frequency of allocation, heap configurations and on memory reclamation. The second tracks down memory leaks1. We have applied these tools to our Scheme compiler, the largest Scheme program we have been developing. This has allowed us to drastically reduce the amount of memory consumed during its bootstrap process, without requiring much development time.Development tools will be neglected unless they are both conveniently accessible and easy to use. In order to avoid this pitfall, we have carefully designed the user interface of these two tools. Their integration into a real programming environment for Scheme is detailed in the paper.

  • Source
    • "Although garbage collection research and development has continued in the Lisp community 4 , nothing has been published recently. To the best of my knowledge, the last garbage collection paper from the Lisp community was published in 2000 [57]. This is a shame. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Garbage collection is a key component of almost all modern programming languages. The advent of con-ventional object-oriented languages supported by managed run-times (e.g. Java, C♯ and even Managed C++) has brought garbage collection into the mainstream and, as memory manager performance is critical for many large applications, brought it to the attention of programmers outside its traditional functional programming language community. In this paper, I review how garbage collection got to where it is today, why it is desirable, what performance you might reasonably expect and I shall outline the directions in which research is moving. In particular, I look at some of the challenges facing modern garbage collection, in contexts ranging from collection for high-performance, multiprocessor systems to collection for real-time systems, from better integrating with its operating environment to supporting specific applications. I speculate on future directions for research.
    Full-text · Article · Jul 2010
  • Source
    • "When applying forgetting functions, some tuples will be deleted from the data warehouse, possibly linked by some referential constraints. This is related to the concept of garbage-collector [5] [21], which is a form of automatic memory management. The principle is to determine what data objects in a program will not be accessed in the future and reclaim the storage used by those objects. "
    [Show abstract] [Hide abstract]
    ABSTRACT: The amount of data stored in data warehouses grows very quickly so that they can get saturated. To overcome this problem, we propose a language for specifying forgetting functions on stored data. In order to preserve the possibility of performing interesting analyses of historical data, the specifications include the definition of some summaries of deleted data. These summaries are aggregates and samples of deleted data and will be kept in the data warehouse. Once forgetting functions have been specified, the data warehouse is automatically updated in order to follow the specifications. This paper presents both the language for specifications, the structure of the summaries and the algorithms to update the data warehouse.
    Full-text · Conference Paper · Apr 2007
  • Source
    • ". Allocated objects vs. dead objects TABLE III STATISTICS OF DEAD OBJECTS KBDB [11] "
    [Show abstract] [Hide abstract]
    ABSTRACT: Scheme uses garbage collection for heap memory management. Ideally, garbage collectors should be able to reclaim all dead objects, i.e. objects that will not be used in future. However, garbage collectors collect only those dead objects that are not reachable from any program variable. Dead objects that are reachable from program variables are not reclaimed. In this paper we describe our experiments to measure the effectiveness of garbage collection in MIT/GNU Scheme. We compute the drag time of objects, i.e. the time for which an object remains in heap memory after its last use. The number of dead objects and the drag time together indicate opportunities for improving garbage collection. Our experiments reveal that up to 26% of dead objects remain in memory. The average drag time is up to 37% of execution time. Overall, we observe memory saving potential ranging from 9% to 65%.
    Full-text · Article · Dec 2006
Show more

We use cookies to give you the best possible experience on ResearchGate. Read our cookies policy to learn more.