VLDB 2026 Research / reviewers in the wild / expert
Fridtjof Siebert
dblp:91/1134
· DBLP profile ↗
8ranked-venue papers
8as first author
0since 2021 · last 2010
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 4 · 4 first-authorSystems, architecture and hardware · 1 · 1 first-authorApplied, interdisciplinary, general and emerging computing · 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 · 46% Concurrent programming · 46% Operating systems · 7% |
Topics — the 5 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 |
0.0 | 1 | 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999 |
Runtime systems and virtual machines › garbage collection
real-time garbage collection |
0.0 | 1 | 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999 |
Concurrent programming
synchronization |
0.0 | 1 | 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999 |
Concurrent programming › synchronization
thread synchronization |
0.0 | 1 | 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999 |
Operating systems › real-time systems
real-time operating systems |
0.0 | 1 | 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999 |
Methods — techniques the papers use, named apart from their topics
preemption · 0.0incremental root scanning · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2010 | Concurrent, parallel, real-time garbage-collectionabstractWith the current developments in CPU implementations, it be-comes obvious that ever more parallel multicore systems will be used even in embedded controllers that require real-time guaran-tees. When garbage collection is used in these systems, parallel and concurrent garbage collection brings important performance advan-tages in the average case. In a real-time system, however, guaran-tees on the GC’s performance in the worst case are required. This paper explains how the single-CPU real-time GC of the Java implementation JamaicaVM was changed to make it a hard real-time garbage collector that is parallel and concurrent. Par-allel means that an arbitrary number of CPUs may perform GC work in parallel, while concurrent means that the GC work can be performed concurrently to the application code without pre-empting the application. In addition, the single units of work that this garbage collector has to perform are very small and uniform and the total amount of GC work is bounded by a function of the heap size, such that it becomes possible for any application that has a bounded amount of reachable memory to run the GC work such that sufficient GC progress can be ensured for the application never to run out of heap space. Fridtjof Siebert |
ISMM | 1 |
| 2009 | JEOPARD -- Java Environment for Parallel Real-Time DevelopmentabstractMulticore systems have become standard for desktop computers today. Current operating systems and software development tools provide straightforward means to use the additional computing power. However, a more fundamental change in the design and development of software is required to fully exploit the power of multicore systems. Furthermore, the fast growing market of embedded systems is currently largely unaffected by the introduction of multicore systems. This will change quickly in the future, which will mean that there will be a demand on efficient development of reliable embedded software that can give real-time guarantees and exploit the available power on multicore systems.The JEOPARD project addresses this demand by developing Java software tools to exploit multicore power while ensuring correctness and predictable timing. This paper gives an overview of the JEOPARD project and focuses on key technical issues such as real-time scheduling and real-time garbage collection on multi-core systems. Fridtjof Siebert |
ISORC | 1 |
| 2008 | Limits of parallel marking garbage collectionabstractMore and more, parallel multicore systems will be used even in low-end devices such as embedded controllers that require realtime guarantees. When garbage collection is used in these systems, parallel or concurrent garbage collection brings important performance advantages. In the context of realtime systems, it has to be shown that a parallel garbage collector implementation not only performs well in most cases, but guarantees on its performance in the worst case are required. Fridtjof Siebert |
ISMM | 1 |
| 2004 | The Impact of Realtime Garbage Collection on Realtime Java ProgrammingabstractExtensions like the real-time specification for Java (RTSJ) enable the use of Java in more and more time-critical application domains. The RTSJ enables the development of realtime code in Java even though a classical garbage collector causes unpredictable pauses to non-realtime code. We give an overview of how a modern realtime garbage collectors operates. It presents the impact the presence of such a realtime garbage collector has on the development of complex applications that need to perform time-critical and nontime-critical tasks. The use of realtime garbage collection technology simplifies the application development even in systems that do not use dynamic memory allocation within realtime code Fridtjof Siebert |
ISORC | 1 |
| 2001 | Constant-Time Root Scanning for Deterministic Garbage Collection
Fridtjof Siebert |
CC | 1 |
| 2000 | Eliminating external fragmentation in a non-moving garbage collector for JavaabstractArticle Eliminating external fragmentation in a non-moving garbage collector for Java Share on Author: Fridtjof Siebert IPD, Universität Karlsruhe, Oberfeldstr. 34B, 76149 Karlsruhe, Germany IPD, Universität Karlsruhe, Oberfeldstr. 34B, 76149 Karlsruhe, GermanyView Profile Authors Info & Claims CASES '00: Proceedings of the 2000 international conference on Compilers, architecture, and synthesis for embedded systemsNovember 2000 Pages 9–17https://doi.org/10.1145/354880.354883Online:01 November 2000Publication History 43citation399DownloadsMetricsTotal Citations43Total Downloads399Last 12 Months12Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access Fridtjof Siebert |
CASES | 1 |
| 1999 | Real-Time Garbage Collection in Multi-Threaded Systems on a Single ProcessorabstractWe show the difficulties that arise for the implementation of a real-time garbage collector (GC) in a multi-threaded system. A mechanism for synchronization between threads is proposed for a single processor system. It is shown how this mechanism can be used to maintain exact information on roots, to do incremental or even constant-time root-scanning and to allow pre-emption of GC activity. Fridtjof Siebert |
RTSS | 1 |
| 1998 | Guaranteeing Non-Disruptiveness and Real-Time Deadlines in an Incremental Garbage CollectorabstractFor Garbage Collection (GC) to be a generally accepted means of memory management it is required to prove its efficiency. This paper presents a scheme that guarantees that an incremental Garbage Collector will have completed its collection cycle before the system runs out of memory. Furthermore, it is shown that the work that has to be done by the collector in one incremental step is limited by a small constant depending on the percentage of total memory used by the application program. This result then allows a suitable trade-off between memory demand and GC overhead to be found. Fridtjof Siebert |
ISMM | 1 |