Demo Data from EDBT 2026 / reviewers in the wild / expert
Phil McGachey
dblp:02/5868
· DBLP profile ↗
3ranked-venue papers
3as first author
0since 2021 · last 2009
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2 · 2 first-authorSystems, architecture and hardware · 1 · 1 first-author
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 · 67% Concurrent programming · 33% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Runtime systems and virtual machines › garbage collection
concurrent garbage collection |
0.1 | 1 | 2008 | Concurrent GC leveraging transactional memory · PPoPP 2008 |
Runtime systems and virtual machines
garbage collection |
0.1 | 1 | 2008 | Concurrent GC leveraging transactional memory · PPoPP 2008 |
Concurrent programming
transactional memory |
0.1 | 1 | 2008 | Concurrent GC leveraging transactional memory · PPoPP 2008 |
Methods — techniques the papers use, named apart from their topics
transactional memory · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2009 | Classifying Java class transformations for pervasive virtualized accessabstractThe indirection of object accesses is a common theme for target domains as diverse as transparent distribution, persistence, and program instrumentation. Virtualizing accesses to fields and methods (by redirecting calls through accessor and indirection methods) allows interposition of arbitrary code, extending the functionality of an application beyond that intended by the original developer. Phil McGachey, Antony L. Hosking, J. Eliot B. Moss |
GPCE | 1 |
| 2008 | Concurrent GC leveraging transactional memoryabstractWe predict that the ever-growing number of cores on our desktops will require a re-examination of concurrent programming. Two technologies are likely to become mainstream in response: Transactional memory provides a superior programming model to traditional lock-based concurrency, while Concurrent GC can take advantage of multiple cores to eliminate perceptible pauses in desktop applications such as games or Internet telephony. This paper proposes a combination of the two technologies, producing a synergy that improves scalability while eliminating the annoyance of user-perceivable pauses. Phil McGachey, Ali-Reza Adl-Tabatabai, Richard L. Hudson, Vijay Menon 0002, Bratin Saha, Tatiana Shpeisman |
PPoPP | 1 |
| 2006 | Reducing generational copy reserve overhead with fallback compactionabstractAs programming languages with managed runtimes become increasingly popular, it is essential that virtual machines are implemented efficiently. The performance of the memory management subsystem can be a defining factor in the performance of the virtualachine as a whole. We present a technique by which garbage collector performance can be improved. We describe an algorithm that combines a standard generational copying collector with a mark and compact collector. We observe that, since most objects do not survive a garbage collection, it is not necessary to reserve space to copy them all. The result is a generational copying collector that operates with a smaller copy reserve overhead than traditional Appel-style collectors. We maintain correctness in the worst case through the use of mark and compact collection. When the reduced copy reserve overflows, a compacting phase ensures that all data are accommodated. We have implemented this algorithm within the framework of Jikes RVM and MMTk. For most benchmarks examined, our experiments show that performance is comparable to or better than a standard generational copying collector. Phil McGachey, Antony L. Hosking |
ISMM | 1 |