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.

Fridtjof Siebert

dblp:91/1134 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Runtime systems and virtual machines
garbage collection
0.011999
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.011999
Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999
Concurrent programming
synchronization
0.011999
Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999
Concurrent programming › synchronization
thread synchronization
0.011999
Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor · RTSS 1999
Operating systems › real-time systems
real-time operating systems
0.011999
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
YearPublicationVenuePosition
2010 Concurrent, parallel, real-time garbage-collection
abstract
With 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
ISMM1
2009 JEOPARD -- Java Environment for Parallel Real-Time Development
abstract
Multicore 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
ISORC1
2008 Limits of parallel marking garbage collection
abstract
More 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
ISMM1
2004 The Impact of Realtime Garbage Collection on Realtime Java Programming
abstract
Extensions 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
ISORC1
2001 Constant-Time Root Scanning for Deterministic Garbage Collection
Fridtjof Siebert
CC1
2000 Eliminating external fragmentation in a non-moving garbage collector for Java
abstract
Article 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
CASES1
1999 Real-Time Garbage Collection in Multi-Threaded Systems on a Single Processor
abstract
We 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
RTSS1
1998 Guaranteeing Non-Disruptiveness and Real-Time Deadlines in an Incremental Garbage Collector
abstract
For 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
ISMM1