Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

David Eby

dblp:76/6770 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 1993
—ORCID · unresolved

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Runtime systems and virtual machines · 91% Programming languages and type systems · 9%

Topics — the 3 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Runtime systems and virtual machines › garbage collection
finalization
0.011993
Guardians in a Generation-Based Garbage Collector · PLDI 1993
Runtime systems and virtual machines
garbage collection
0.011993
Guardians in a Generation-Based Garbage Collector · PLDI 1993
Runtime systems and virtual machines › garbage collection
generational garbage collection
0.011993
Guardians in a Generation-Based Garbage Collector · PLDI 1993
YearPublicationVenuePosition
1993 Guardians in a Generation-Based Garbage Collector
abstract
This paper describes a new language feature that allows dynamically allocated objects to be saved from deallocation by an automatic storage management system so that clean-up or other actions can be performed using the data stored within the objects. The program has full control over the timing of clean-up actions, which eliminates several potential problems and often eliminates the need for critical sections in code that interacts with clean-up actions. Our implementation is “generation-friendly” in the sense that the additional overhead within a generation-based garbage collector is proportional to the work already done there, and the overhead within the mutator is proportional to the number of clean-up actions actually performed.
R. Kent Dybvig, Carl Bruggeman, David Eby
PLDI3