Demo Data from VLDB 2026 / reviewers in the wild / expert
Irit Goft
dblp:55/6057
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2005
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2
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
2 papers |
Runtime systems and virtual machines · 100% |
Topics — the 4 heaviest of 5, 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 | 2 | 2005 | A parallel, incremental, mostly concurrent garbage collector for servers · ACM Trans. Program. Lang. Syst. 2005 A Parallel, Incremental and Concurrent GC for Servers · PLDI 2002 |
Runtime systems and virtual machines
garbage collection |
0.1 | 2 | 2005 | A parallel, incremental, mostly concurrent garbage collector for servers · ACM Trans. Program. Lang. Syst. 2005 A Parallel, Incremental and Concurrent GC for Servers · PLDI 2002 |
Runtime systems and virtual machines › garbage collection
parallel garbage collection |
0.1 | 2 | 2005 | A parallel, incremental, mostly concurrent garbage collector for servers · ACM Trans. Program. Lang. Syst. 2005 A Parallel, Incremental and Concurrent GC for Servers · PLDI 2002 |
Runtime systems and virtual machines › garbage collection
incremental garbage collection |
0.0 | 1 | 2002 | A Parallel, Incremental and Concurrent GC for Servers · PLDI 2002 |
Methods — techniques the papers use, named apart from their topics
work packet mechanism · 0.0memory fence batching · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2005 | A parallel, incremental, mostly concurrent garbage collector for serversabstractMultithreaded applications with multigigabyte heaps running on modern servers provide new challenges for garbage collection (GC). The challenges for “server-oriented” GC include: ensuring short pause times on a multigigabyte heap while minimizing throughput penalty, good scaling on multiprocessor hardware, and keeping the number of expensive multicycle fence instructions required by weak ordering to a minimum.We designed and implemented a collector facing these demands building on the mostly concurrent garbage collector proposed by Boehm et al. [1991]. Our collector incorporates new ideas into the original collector. We make it parallel and incremental; we employ concurrent low-priority background GC threads to take advantage of processor idle time; we propose novel algorithmic improvements to the basic mostly concurrent algorithm improving its efficiency and shortening its pause times; and finally, we use advanced techniques, such as a low-overhead work packet mechanism to enable full parallelism among the incremental and concurrent collecting threads and ensure load balancing.We compared the new collector to the mature, well-optimized, parallel, stop-the-world mark-sweep collector already in the IBM JVM. When allowed to run aggressively, using 72% of the CPU utilization during a short concurrent phase, our collector prototype reduces the maximum pause time from 161 ms to 46 ms while only losing 11.5% throughput when running the SPECjbb2000 benchmark on a 600-MB heap on an 8-way PowerPC 1.1-GHz processors. When the collector is limited to a nonintrusive operation using only 29% of the CPU utilization, the maximum pause time obtained is 79 ms and the loss in throughput is 15.4%. Katherine Barabash, Ori Ben-Yitzhak, Irit Goft, Elliot K. Kolodner, Victor Leikehman, Yoav Ossia, Avi Owshanko, Erez Petrank |
ACM Trans. Program. Lang. Syst. | 3 |
| 2002 | A Parallel, Incremental and Concurrent GC for ServersabstractMultithreaded applications with multi-gigabyte heaps running on modern servers provide new challenges for garbage collection (GC). The challenges for "server-oriented" GC include: ensuring short pause times on a multi-gigabyte heap, while minimizing throughput penalty, good scaling on multiprocessor hardware, and keeping the number of expensive multi-cycle fence instructions required by weak ordering to a minimum. We designed and implemented a fully parallel, incremental, mostly concurrent collector, which employs several novel techniques to meet these challenges. First, it combines incremental GC to ensure short pause times with concurrent low-priority background GC threads to take advantage of processor idle time. Second, it employs a low-overhead work packet mechanism to enable full parallelism among the incremental and concurrent collecting threads and ensure load balancing. Third, it reduces memory fence instructions by using batching techniques: one fence for each block of small objects allocated, one fence for each group of objects marked, and no fence at all in the write barrier. When compared to the mature well-optimized parallel stop-the-world mark-sweep collector already in the IBM JVM, our collector prototype reduces the maximum pause time from 284 ms to 101 ms, and the average pause time from 266 ms to 66 ms while only losing 10% throughput when running the SPECjbb2000 benchmark on a 256 MB heap on a 4-way 550 MHz Pentium multiprocessor. Yoav Ossia, Ori Ben-Yitzhak, Irit Goft, Elliot K. Kolodner, Victor Leikehman, Avi Owshanko |
PLDI | 3 |