Demo Data from VLDB 2026 / reviewers in the wild / expert
Peter B. Kessler
dblp:12/4153
· DBLP profile ↗
3ranked-venue papers
1as first author
0since 2021 · last 2019
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 3 · 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
2 papers |
Runtime systems and virtual machines · 33% Compilers and program optimization · 33% Program analysis · 33% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Cloud and datacenter computing · 100% |
Topics — the 4 heaviest of 6, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Compilers and program optimization › compiler construction
ahead-of-time compilation |
0.4 | 1 | 2019 | Initialize once, start fast: application initialization at build time · Proc. ACM Program. Lang. 2019 |
Program analysis › static analysis
pointer analysis |
0.4 | 1 | 2019 | Initialize once, start fast: application initialization at build time · Proc. ACM Program. Lang. 2019 |
Cloud and datacenter computing
serverless computing |
0.4 | 1 | 2019 | Initialize once, start fast: application initialization at build time · Proc. ACM Program. Lang. 2019 |
Debugging and program repair › debugging tools
debugger implementation |
0.0 | 1 | 1990 | Fast Breakpoints: Design and Implementation · PLDI 1990 |
Methods — techniques the papers use, named apart from their topics
points-to analysis · 0.8heap snapshotting · 0.8copy-on-write · 0.8
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2019 | Initialize once, start fast: application initialization at build timeabstractArbitrary program extension at run time in language-based VMs, e.g., Java's dynamic class loading, comes at a startup cost: high memory footprint and slow warmup. Cloud computing amplifies the startup overhead. Microservices and serverless cloud functions lead to small, self-contained applications that are started often. Slow startup and high memory footprint directly affect the cloud hosting costs, and slow startup can also break service-level agreements. Many applications are limited to a prescribed set of pre-tested classes, i.e., use a closed-world assumption at deployment time. For such Java applications, GraalVM Native Image offers fast startup and stable performance. GraalVM Native Image uses a novel iterative application of points-to analysis and heap snapshotting, followed by ahead-of-time compilation with an optimizing compiler. Initialization code can run at build time, i.e., executables can be tailored to a particular application configuration. Execution at run time starts with a pre-populated heap, leveraging copy-on-write memory sharing. We show that this approach improves the startup performance by up to two orders of magnitude compared to the Java HotSpot VM, while preserving peak performance. This allows Java applications to have a better startup performance than Go applications and the V8 JavaScript VM. Christian Wimmer, Codrut Stancu, Peter Hofer, Vojin Jovanovic, Paul Wögerer, Peter B. Kessler, Oleg Pliss, Thomas Würthinger |
Proc. ACM Program. Lang. | 6 |
| 1990 | Fast Breakpoints: Design and Implementation
Peter B. Kessler |
PLDI | 1 |
| 1983 | An Execution Profiler for Modular ProgramsabstractAbstract In modular programs, groups of routines constitute conceptual abstractions. A method for providing execution profiles for such programs is presented. The central idea is that the execution time for a routine is charged to the routines that call it. The implementation of this method by a profiler called gprof is described. The techniques used to gather the necessary information about the timing and structure of the program are given, as is the processing used to propagate routine execution times along arcs of the call graph of the program. The method for displaying the profile to the user is discussed. Experience using the profiles for hand‐tuning large programs is summarized. Additional uses for the profiles are suggested. Susan L. Graham, Peter B. Kessler, Marshall K. McKusick |
Softw. Pract. Exp. | 2 |