Managed Programming Languages and Runtimes 2022

Abstract of the opening session.

Abstract of the opening session.

In this talk we will look at a few interesting optimizations done in the .NET GC. One of the .NET GC’s principles is to separate mechanisms from policies which allows for much more dynamic tuning decisions. We will also use these optimizations to illustrate this principle. How does the .NET GC organize its objects on the heap when processing them during various GC phases? It groups adjacent live objects into what’s called plugs and uses dead objects inbetween them, called gaps, to store necessary info to facilitate relocation. Special handling is done for pinned objects. Dead spaces inbetween pinned plugs which are threaded onto a free list can get used sooner to satisfy allocation requests by a mechanism called demotion. And we can decide if we want to make them available sooner by separating mechanisms from policies. The GC can also make a decision whether it’s more productive to do a compacting or sweeping GC after calculating the relocation information (another example of separating mechanisms from policies). If it turns out to be a sweeping GC, the allocations done in the free list of the older generation will need to be repaired. We repair this by an UNDO field on each free list item and keeping a count on the original free list item we took off for allocation, and we only need to repair that many when threading back the items whose UNDO field was touched.

JavaScript is particularly difficult to implement efficiently because most of its expressions have all sorts of different meanings that involve all sorts of different executions that are not distinguished by any syntactic or type annotation. The common intuition is that only JIT compilers can handle it efficiently because they can rely on heuristic-based strategies that require having the program and the data on hand. But static (AOT) compilers can speculate and use heuristics too! To demonstrate that, we propose Hopc, an AOT compiler for JavaScript, based on the following assumption The most likely data structure a program will use is the one for which the compiler is able to produce its best code. Thus, contrary to most AOT compilers, Hopc does not rely on complex static analyses to optimize programs. It simply tries to generate its best code that it protects with guards. In this presentation, I will present its main optimizations and an in-depth performance analysis.

Around 1978 I wrote my first garbage collector, in PDP-10 assembly code, for the Clu language being developed by Barbara Liskov's group at MIT. From the 1980s to the present I've been involved with garbage collection research as one of the main threads of my work. In these reflections I try to glean what patterns I can, with hope that younger generations of researchers may find something useful in them. While I formally retired in 2020, I continue to be active in research and will offer a few thoughts about the future as well as the past.

Abstract of the opening session.

Abstract of the opening session.

Abstract of the opening session.

Abstract of the opening session.

Abstract of the opening session.

Abstract of the opening session.

Today's huge memories make it possible to store and process large data structures in memory instead of in a database. Hence, accesses to this data should be optimized, which is normally relegated either to the runtimes and compilers or is left to the developers, who often lack the knowledge about optimization strategies. As arrays are often part of the language, developers frequently use them as an underlying storage mechanism. Thus, optimization of arrays may be vital to improve performance of data-intensive applications. While compilers can apply numerous optimizations to speed up accesses, it would also be beneficial to adapt the actual layout of the data in memory to improve cache utilization. However, runtimes and compilers typically do not perform such memory layout optimizations.
In this work, we present an approach to dynamically perform memory layout optimizations on arrays of objects to transform them into a columnar memory layout, a storage layout frequently used in analytical applications that enables faster processing of read-intensive workloads. By integration into a state-of-the-art JavaScript runtime, our approach can speed up queries for large workloads by up to 9x, where the initial transformation overhead is amortized over time.

How concurrent compacting collectors store and manage their forwarding information is crucial for their overall performance. In this work, we address a pathological case of the two most common techniques for storing forwarding information that can lead to an explosion in the amount of memory needed to store forwarding addresses, up to 100% of the managed heap.
We propose CFW, a representation technique for forwarding information that guarantees that forwarding information for an entire heap can be stored in at most 3.14% of its size. By providing such a guarantee, we simplify the task of deploying programs with respect to memory needs. This is important given how memory is typically the dominating factor in the cost model for cloud-based deployments.
We explore the design space of our technique through a prototype implementation on-top of ZGC. A rigorous performance evaluation shows promising results.

Debugging IoT applications is challenging due to the hardware constraints of IoT devices, making advanced techniques like record-replay debugging impractical. As a result, programmers often rely on manual resets, or inefficient and time-consuming debugging techniques such as printf. Although simulators can help in that regard, their applicability is limited because they fall short of accurately simulating and reproducing the runtime conditions where bugs appear.
In this work, we explore a novel debugging approach, called event-based out-of-place debugging in which developers can capture a remotely running program and debug it locally on a (more powerful) machine. Our approach provides rich debugging features (e.g., step-back) that normally would not run on the hardware restricted devices by leveraging the developer's machine.
Two different strategies are offered to deal with resources which cannot be easily transferred (e.g. sensors): pull-based (akin to remote debugging), or push-based (where data updates are pushed to developer's machine during the debug session). We present EDWARD, an event-based out-of-place debugger prototype, implemented by extending the WARduino WebAssembly microcontroller Virtual Machine, that has been integrated into Visual Studio Code. To validate our approach, we show how our debugger helps uncover IoT bugs representative of real-world applications through several use-case applications. Initial benchmarks show that event-based out-of-place debugging can drastically reduce debugging latency.

Compiler optimizations are often based on hand-crafted heuristics to guide the optimization process. These heuristics are designed to benefit the average program and are otherwise static or only customized by profiling information. We propose machine-learning-based self-optimizing compiler heuristics, a novel approach for fitting optimization decisions in a dynamic compiler to specific environments. This is done by updating a machine learning model with extracted performance data at run time. Related work—which primarily targets static compilers—has already shown that machine learning can outperform hand-crafted heuristics. Our approach is specifically designed for dynamic compilation and uses concepts such as deoptimization for transparently switching between generating data and performing machine learning decisions in single program runs. We implemented our approach in the GraalVM, a high-performance production VM for dynamic compilation. When evaluating our approach by replacing loop peeling heuristics with learned models we encountered speedups larger than 30% for several benchmarks and only few slowdowns of up to 7%.

Trusted execution environments (TEEs) gained significant traction in recent years. They have become the foundation of Confidential Computing in cloud services, where certain security properties can be guaranteed on untrusted servers. Despite this adoption, writing code to target TEEs remains challenging. The SDKs for popular TEE implementations, like Intel SGX, are aimed at low-level languages like C/C++. Previous research has introduced support for developing and running programs written in managed programming languages in a TEE environment. However, in these works, the language runtime is embedded into the TEE, increasing the Trusted Computing Base (TCB) and thus inherently reducing trust into the TEE itself. To solve this problem, we propose a new approach to integrate the development of TEE code in managed languages, without the need to embed the full language runtime inside the TEE. It allows developers to write the TEE logic as part of their program in a managed programming language. Using the existing compiler infrastructure, the TEE logic is extracted and passed to a source-to-source compiler that transforms it into a low-level unmanaged equivalent. The resulting low-level code is then compiled by the compiler toolchain targeting the TEE platform. This paper reports on the design and the first results of our work-in-progress implementation of SecSharp, a tool to enable TEE development in C#.

Garbage collectors provide memory safety, an important step toward program correctness. However, correctness of the collector itself can be challenging to establish, given both the style in which such systems are written and the weakly-ordered memory accesses of modern hardware. One way to maximize benefits is to use a framework in which effort can be focused on the correctness of small, modular critical components from which various collectors may be composed.
Full proof of correctness is likely impractical, so we propose to gain a degree of confidence in collector correctness by applying model checking to critical kernels within a garbage collection framework. We further aim for a model framework, paralleling the framework nature of the collector, in hope that it will be easy to create new models for new collectors.
We describe here a prototype model structure, and present results of model checking both stop-the-world and snapshot-at-the-beginning concurrent marking. We found useful regularities of model structure, and that models could be checked within possible time and space budgets on capable servers. This suggests that collectors built for the new framework might be model checked, and further that it may be worthwhile to develop a domain-specific language from which to generate those models.

The RISC-V Instruction Set Architecture (ISA) is an open-source, modular and extensible ISA. The ability to add new instructions into a dedicated core opens up perspectives to accelerate VM components or provide dedicated hardware IPs to applications running on top. However, the RISC-V ISA design is clashing on several aspects with other ISAs and therefore software historically built around them. Among them, the lack of condition codes and instruction expansion through simple instruction combination. In this paper we present the challenges of porting Cogit, the Pharo’s JIT compiler tightly linked to the x86 ISA, on RISC-V. We present concrete examples of them and the rationale behind their inclusion in the RISC-V ISA. We show how those mismatches are solved through design choices of the compilation process or through tools helping development: a VM simulation framework to keep the development in a high-level environment for the most part, an ISA-agnostic test harness covering main VM functionalities and a machine code debugger to explore and execute generated machine code. We also present a way to prototype custom instructions and execute them in the Pharo environment.

Sustainable computing needs energy-efficient software. This paper explores the potential of leveraging the nature of software written in managed languages: increasing energy efficiency by changing a program's memory management strategy without altering a single line of code. To this end, we perform comprehensive energy profiling of 35 Java applications across four benchmarks. In many cases, we find that it is possible to save energy by replacing the default G1 collector with another without sacrificing performance. Furthermore, potential energy gains can be even higher if performance regressions are permitted. Inspired by these results, we study what the most energy-efficient GCs are to help developers prune the search space for energy profiling at a low cost. Finally, we show that machine learning can be successfully applied to the problem of finding an energy-efficient GC configuration for an application, reducing the cost even further.

Automatic memory management relieves programmers of the burden of having to reason about object lifetimes in order to soundly reclaim allocated memory. However, this automation comes at a cost. The cost and benefits of garbage collection have been the subject of contention for a long time, and will likely remain so. However, until now, the question is surprisingly under-studied.
We examine the costs and benefits of garbage collection through four studies, exploring: (i) the space-overheads of garbage collection; (ii) the effects of garbage collection on the execution time of a mutator using a free list allocator; (iii) how proximity to garbage collection events affects mutator performance; and (iv) the effects of the delay in memory reuse on manually managed workloads. We conduct this study in a contemporary setting using recent CPU microarchitectures allowing us to shed new light on garbage collection overheads in a modern context.
We find that: (i) simple, fully-copying collectors such as SemiSpace have average space overheads of 1.70x, while Immix has an overhead of 1.13x a baseline approximating manual memory management; (ii) for the collection frequencies we evaluate, garbage collection has little impact on a mutator using an optimized free list allocator; (iii) the proximity of mutator work to the nearest collection has little impact on its performance, unless a free list allocator is used; and (iv) postponing the reuse of memory has only a modest effect in terms of time and space. The costs and benefits of garbage collection are likely to remain subject to contentious discussion. However, the methodologies and evaluations we present here provide a deeper understanding of the differences in costs between manual memory management and garbage collection.

Dynamic taint analysis is a popular analysis technique which tracks the propagation of specific values while a program executes. To this end, a taint label is attached to these values and is dynamically propagated to any values derived from them. Frequent application of this analysis technique in many fields has led to the development of general-purpose analysis platforms with taint propagation capabilities. However, these platforms generally limit analysis developers to a specific implementation language, to specific propagation semantics or to specific taint label representations.
In this paper we present label-defined dynamic taint analysis, a language-agnostic approach for specifying the properties of a dynamic taint analysis in terms of propagated taint labels. This approach enables analysis platforms to support arbitrary adaptations to these properties by delegating propagation decisions to propagated taint labels and thus to provide more flexibility to analysis developers than other analysis platforms. We implemented this approach in TruffleTaint, a GraalVM-based taint analysis platform, and integrated it with GraalVM's language interoperability and tooling support. We further integrated our approach with GraalVM's performance optimizations. Our performance evaluation shows that label-defined taint analysis can reach peak performance similar to that of equivalent engine-integrated taint analyses. In addition to supporting the convenient reimplementation of existing dynamic taint analyses, our approach enables new capabilities for these analyses. It also enabled us to implement a novel tooling infrastructure for analysis developers as well as tooling support for end users.

Abstract of the opening session.

Vector instructions are a class of processor instructions that allow data level parallelism by performing the same instruction on multiple pieces of data, instead of a single one as usual. On managed runtimes, special support from the virtual machine is required to generate vector instructions for the host machine’s architecture. There are two possible approaches to achieve this: add virtual machine intrinsics that use vector instructions, or extend the bytecode set with vector operations that are then mapped to processor vector instructions. Intrinsics are methods implemented at the VM level, using native code. They allow low-level control of the operations being performed and are generally used to build entire operations, such as sorting an array or adding two arrays together. Bytecode operations, on the other hand, are usually designed to be composable. For example, the operation of adding two arrays can be composed of bytecodes to load a part of an array into a vector register, one to add the vector registers, and one to store the result back into an array. We implemented both approaches in the Pharo VM and analyzed the impact of such safety checks on performance. We found that the most significant difference in performance between intrinsic methods and bytecode operations stems from the latter performing redundant type checking on bytecode's parameters, bounds checking on array accesses, and overflow tests on array iterators. These checks are necessary since bytecodes can be composed in arbitrary sequences, and so they need to prevent invalid ones from causing catastrophic errors. This requires setting up safety checks on each bytecode to ensure that each operates with valid parameters. However, once a bytecode sequence is formed, some of these checks could be removed without compromising the correctness of that sequence. We propose existing compiler optimizations than could be used to reduce the impact of these checks on performance, although we have not yet evaluated their effectiveness.

The Garbage Collector in PharoVM takes human perceivable pauses (~3 seconds) on big heaps (more than 4 GB). One of the reasons is that it must traverse the entire memory searching for collectable objects. However, lot of objects will almost never garbage collected, like classes, methods, literals. We are developing a Permanent Space for the generational Garbage Collector to allocate these kind of objects. Also, to be worth enough, we need to select a smart object graph to move to this space. We are making benchmarks over some possible scenarios and analysing the resulted object graph thru simulations in order to understand what are the best constraints to select these objects. We present preliminaries results and open questions from this work in progress.

Debugging IoT applications is challenging due to the hardware constraints of IoT devices, making advanced techniques like record-replay debugging impractical. As a result, programmers often rely on manual resets, or inefficient and time-consuming debugging techniques such as printf. Although simulators can help in that regard, their applicability is limited because they fall short of accurately simulating and reproducing the runtime conditions where bugs appear. In this work, we explore a novel debugging approach, called event-based out-of-place debugging in which developers can capture a remotely running program and debug it locally on a (more powerful) machine. Our approach provides rich debugging features (e.g., step-back) that normally would not run on the hardware restricted devices by leveraging the developer's machine. Two different strategies are offered to deal with resources that cannot be easily transferred (e.g. sensors): pull-based (akin to remote debugging), or push-based (where data updates are pushed to developer's machine during the debug session). We present EDWARD, an event-based out-of-place debugger prototype, implemented by extending the WARduino WebAssembly microcontroller Virtual Machine, that has been integrated into Visual Studio Code. To validate our approach, we show how our debugger helps uncover IoT bugs representative of real-world applications through several use-case applications. Initial benchmarks show that event-based out-of-place debugging can drastically reduce debugging latency.

WebAssembly, known as Wasm, is an interpreted portable bytecode execution format that is growing in popularity. In this work, we perform a simple pair of characterizations of Wasm. Statically, we compare the instruction set to other portable bytecodes like JVM and PCODE, showing that Wasm operates at a lower abstraction level than JVM, similar to PCODE. Dynamically, we study the Wasm instruction mix for a set of common benchmark applications. This investigation reveals that, like JVM, data movement operations occur most frequently in instruction traces. We conclude by discussing possible future directions for optimizing Wasm execution.

Many garbage collectors move live objects to avoid fragmentation and as a way to free memory. When an object is moved, all its incoming pointers must be remapped to its new location. However, at the point when the object is moved, its incoming pointers are not known. Thus, garbage collectors must collect and manage forwarding information that allows remapping outdated addresses. Because of the relatively large sizes of pointers in 64-bit systems with large heaps, the amount of memory needed to store forwarding information can become theoretically as large as the heaps whose addresses they are remapping. While unlikely, the size of forwarding information needed at different times throughout the lifetime of a program is both hard to predict and completely beyond programmer control. In this work, we present a technique for compressing forwarding information that guarantees that the amount of memory needed to remap a heap is at most 3.14% of the size of the heap. We show that our technique can be applied to industry-grade ZGC in OpenJDK with negligible performance impact.

Performance is often critical in the context of large-scale web-applications. Achieving it is non-trivial, especially for applications written in dynamic languages such as Ruby, where it is common to use reflection and many small methods. For such languages, we need good just-in-time compilation, which in turn relies heavily on lookup caches, splitting, and inlining. We studied the impact of these optimisations on the call-site behaviour of 76 Ruby benchmarks. This poster presents our findings: we show that the combined use of lookup caches, splitting, and the elimination of targets in lookup caches leads to a quasi-complete monomorphisation of all the polymorphic call-sites of our benchmark set. Monomorphisation is beneficial for performance, as it enables fast call resolution, and other optimisations such as inlining. However, our analysis also suggests these call-site optimisations, notably splitting, are too aggressive, leading to unnecessarily cloning of methods, which increases the memory footprint and compilation overhead of the application. To address this issue, we suggest extending contextual dispatch [1] for the use in splitting heuristics for Ruby. Originally, contextual dispatch uses calling-context information to enable optimisations, notably by dispatching to compiled functions for a specific context. This improves both execution time and memory footprint, as the pre-specialized functions can be shared between call-sites with the same context signature. We present our idea of how to extend this logic to guide the splitting heuristics based on argument-types. We show the potential impact of such an approach on the program’s inner representation. This approach is yet-to-be implemented. In the future, we will also explore how richer contextual information, going beyond argument-types, such as specific object properties, or the call-chain structure, can further guide splitting decisions. [1] Flückiger, O., Chari, G., Yee, M. H., Ječmen, J., Hain, J., & Vitek, J. (2020). Contextual dispatch for function specialization. Proceedings of the ACM on Programming Languages, 4(OOPSLA), 1-24.

Debugging IoT applications is challenging due to the hardware constraints of IoT devices. This makes advanced techniques like record-replay debugging impractical. As a result, developers often rely on manual resets or inefficient and time-consuming debugging techniques such as printf. Although simulators can help in that regard, their applicability is limited because they fall short of accurately simulating and reproducing the runtime conditions where bugs appear. This demonstration is aimed at participants interested in programming and debugging IoT applications. The demo introduces a new debugging approach for IoT applications through EDWARD, which is, a debugger that implements a novel IoT debugging technique called event-based out-of-place debugging within an existing WebAssembly VM for microcontrollers called WARDuino. With EDWARD developers can on-demand capture a remotely running IoT application and debug it locally at the developer's machine. As a result, developers can debug on a more powerful machine and benefit from low debugging interference as well as advanced debugging features such as step-back which normally would not run on hardware-restricted devices. To deal with the absence of device resources on the developer's machine (e.g., sensors, buttons, etc.), EDWARD implements two access strategies: (1) developers can issue a request of the value of the device resource (e.g., read from the temperature sensor plugged into the device), or (2) developers can register for notifications when changes happen at the resource so that the value is pushed to the developers (e.g., notifies of button presses on the device). We implemented our prototype debugger interface as a VSCode plugin that lets developers apply classical debugging operations (e.g., add breakpoint, step, etc.), gives fine-grained control over the access to the device resources, and lets developers commit source code changes (over the air) to the remote device after fixing a bug.

A significant portion of today’s applications use managed runtime languages like Java, and therefore, take advantage of automatic memory management, also commonly known as Garbage Collection (GC). GC is a key attribute in managed runtimes as it eliminates developers’ effort to manually allocate and deallocate the objects in memory, thus improving developer productivity. GC algorithms may significantly affect application performance goals, especially those dealing with large data (which may focus on throughput) and substantial transaction rates (which may focus on latency). However, there is still no tool to help users and developers to overcome the challenges of selecting a suitable GC solution for their applications. Several GC algorithms are available in different Java versions attempting to improve performance metrics like throughput, pause time, and memory footprint. As these performance metrics are the most common, we consider them to be the most critical metrics that highly affect the user’s applications. This study follows a simple yet effective methodology to evaluate four well-known production collectors considering throughput and pause time while the memory available to collectors changes. Then, we propose an approach to recommend a suitable collector for a user’s application while letting the user decide on his performance priority.

Picking the right data structure for the right job is one of the key challenges for every developer. However, especially in the realm of object-oriented programming, the memory layout of data structures is often still suboptimal for certain data access patterns, due to objects being scattered across the heap. Therefore, this work presents an approach for the automated transformation of arrays of objects into a contiguous format (called columnar arrays). At run time, we identify suitable arrays, perform the transformation and use a dynamic compiler to gain performance improvements. In the evaluation, we show that our approach can improve the performance of certain queries over large, uniform arrays.

The Truffle framework allows language implementations to reach state-of-the-art run time performance while only providing an abstract syntax tree (AST) interpreter; the AST is compiled to machine code using GraalVM's JIT compiler. However, it can take some time before this fully optimized code is generated and executed: startup performance is consequently tightly bound to interpreter performance, therefore reducing the execution time requires us to improve interpreter performance instead of solely focusing on the JIT compiler. Through the use of a novel technique called supernodes, we take steps towards improving the run-time performance of Truffle-based interpreters, aiming to reduce programs' overall execution time by improving interpreter performance. We take inspiration from a well-known bytecode interpreter optimization technique: superinstructions, which reduce the instruction dispatch overhead by concatenating existing instructions. In the case of supernodes, AST nodes are merged, creating a single entity which has the same behavior as the original tree. The main performance gain of supernodes comes from removing redundant node safety guards: for instance, regular nodes have to check the type of their input data through a type guard, even though it may have already been determined by another node which had no way of sharing this information. Supernodes avoid this problem through unifying the node contexts. Moreover, similarly to superinstructions, performance is also gained through reducing the node dispatch overhead as a result of using fewer nodes. So far, we have been relying on the research language TruffleSOM, a minimal Smalltalk dialect implemented using Truffle, and we are focusing on the Are We Fast Yet benchmark suite, which contains both micro- and macro- benchmarks. Initial results are promising, showing up to 42% run time reduction with the addition of 20 supernodes. Moreover, there are currently no performance regressions for any of our benchmarks compared to a baseline with no supernode candidates available. However, node trees that yield valuable supernodes are currently detected manually, and the process of generating supernodes from them is currently not automated. In the future, we aim to develop heuristics to identify potential supernode candidates: both at parsing time through static analysis, as well as later during run time through detection of frequently called nodes that could yield performance gains should they be merged together. The supernodes would then be generated based on the code of the selected AST nodes. In addition, we aim to port our technique to more complex Truffle implementations used in the industry, such as GraalPython or TruffleRuby.

Dynamic taint analysis assigns taint labels to sensitive data and tracks the propagation of such tainted data during program execution. This program analysis technique has been implemented in various analysis platforms targeting specific programming languages or program representations and it has been applied to diverse fields such as software security and debugging. While some of these platforms support customization of their taint analysis, this customization is typically limited to certain analysis properties or to predefined options. This limitation can require analysis developers to modify the analysis engine itself in order to adapt other analysis properties or to implement new taint analysis applications. We designed label-defined dynamic taint analysis as a new approach to specifying a dynamic taint analysis in terms of taint labels. This approach enables an analysis platform to allow analysis developers to adapt arbitrary analysis properties without modifying the platform itself. We implemented this approach in TruffleTaint, a GraalVM-based dynamic taint analysis platform targeting multiple programming languages. Our prototype supports implementing taint analyses in multiple programming languages and further provides tooling support for analysis development. In this tool demonstration we will present the capabilities of our prototype and demonstrate the implementation of label-defined dynamic taint analyses with common adaptations to various analysis properties.

The Pharo language is an object-oriented programming language based on Smalltalk [1] featuring a JIT compiler to mitigate the overhead of the virtual machine interpreting instructions. Currently, Pharo’s JIT compiler consists of handwritten machine code templates that correspond to bytecode instructions. These templates, however, duplicate the behaviour of the bytecode interpreter. To solve this code duplication, a compiler was recently introduced to compile these machine code templates based on the interpreter is in development. Such a JIT compiler compiler is called Druid and it's currently under development. In this poster, we present semantic-preserving optimizations added to Druid to eliminate redundant code. In particular, we introduce global value numbering (GVN) and investigate the effects it has when combined with other optimizations like Conditional Constant Propagation (SCCP) and Dead Code Elimination (DCE). We implement a GVN approach based on a dominator tree encoding dominator relationships in the control-flow graph that is used to determine what expressions will always be live in a given basic block. The motivation for implementing dominator-based value numbering (DNVT) is that it fully utilizes the intermediate representation Druid uses. More concretely, the existing control-flow graph allows for quickly computing the dominator tree and static single assignment (SSA) form is the key to assigning value numbers to every expression in the program without doing live analysis. We validated our approach by comparing the percentage of instructions being removed by DVNT with respect to other optimizations on basic operations such SCPP and DCE. Preliminary results show that DVNT removes a lot of instructions compared to DCE and SCCP. Moreover, combining multiple optimizations allows for more optimized code.

The Boehm-Demers-Weiser collector is a conservative garbage collection scheme generally used for C/C++ applications. In this demo, we will show the collector running with C benchmark programs on a new CHERI-style hardware capability platform, specifically the Arm Morello system.