# Efficient Memory Usage For Edge FaaS Platforms

Djob Mvondo, Boris Djomgwe Teabe, Nikos Parlavantzas

## ► To cite this version:

Djob Mvondo, Boris Djomgwe Teabe, Nikos Parlavantzas. Efficient Memory Usage For Edge FaaS Platforms. PerCom 2026 - 24th IEEE International Conference on Pervasive Computing and Communications, IEEE, Mar 2026, Pise, Italy. hal-05465369v2

HAL Id: hal-05465369

https://inria.hal.science/hal-05465369v2

Submitted on 1 Feb 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
Efficient Memory Usage For Edge FaaS Platforms

Djob Mvondo

Boris Teabe

Nikos Parlavantzas

Univ Rennes, Inria, CNRS, IRISA

IRIT, Univ Toulouse, CNRS

INSA Rennes, Inria, CNRS, IRISA

*Abstract*—Function as a Service (FaaS) is a great fit for data and event processing in Edge environments. These environments are characterized by resource-constrained devices that require efficient memory usage optimizations. Existing optimization solutions for memory in high-end clusters such as data centers cannot be used in Edge environments because they either depend on unavailable hardware features such as RDMA or require resource-intensive analysis such as periodic memory scanning, compression, or decompression.

In this paper, we introduce *Extensible RUNtimes* (ERUN), a lightweight mechanism for existing FaaS runtimes aimed at optimizing memory utilization by reducing the memory usage of idle sandboxes (i.e., those awaiting function execution). ERUN operates through two main actions: *Shrink* and *Expand*. The *Shrink* operation unloads libraries and reclaims memory from the sandboxes, while the *Expand* operation quickly reloads the libraries when a function is executed. The *Expand* operation leverages an in-memory store that maintains a single instance of discarded libraries on the node. We implement the ERUN mechanism, which can be applied to any runtime environment, in a Python runtime. We extensively evaluated our prototype in a 10-node Edge cluster using 10 popular FaaS functions. The results show that ERUN reduces idle sandbox memory usage by up to 23.13× and improves the warm-start ratio by 1.38×, with less than 2% overhead on execution time and energy usage.

# I. INTRODUCTION

FaaS, edge FaaS, and keep-alive strategies. The Function-as-a-Service (FaaS) model is an increasingly popular cloud computing model that enables developers to run event-driven code without having to manage servers. In FaaS, developers ship code in the form of functions and configure events that trigger function execution within isolated sandbox environments. Although FaaS was initially designed for cloud applications, its event-driven execution model also makes it well suited for edge computing, where devices close to the network edge process events triggered by sensors [1]. Edge computing is motivated by the need for low-latency data processing, essential in use cases such as wearable cognitive assistance assisted driving and camera surveillance systems. Beyond its support for event processing, FaaS brings further advantages in edge use cases, including removing the need for always-on resources and allowing automatic, fine-grained scaling. Consequently, several research efforts investigate edge FaaS platforms, focusing on storage, CPU provisioning and task placement, and runtimes and frameworks.

A central challenge for all FaaS platforms is the cold start problem, that is, the performance overhead of initializing a new sandbox prior to executing a function. Cold starts severely affect the latency of functions, and cold-start mitigating solutions have remained a consistent focus of the research

community [2–4]. Cold starts are especially problematic in edge environments where low-latency responses are critical. To address the cold start challenge, FaaS platforms typically implement a *keep-alive strategy*, which keeps a sandbox alive for a fixed period after the running function ends its execution. The goal is to reuse the sandbox for a similar function in the future, thus preventing sandbox initialization.

Keep-alive memory waste mitigation and limitations for edge FaaS. Keep-alive strategies can leave sandboxes idle during a non-negligible slice of their lifetime. A recent study shows that at least 25% of sandboxes are idle 50% of their lifetime [5]. Idle sandboxes retain memory that other functions cannot use, leading to memory waste (Section III). This memory waste limits the number of function instances that can be hosted on a node, which can lead to more cold starts and reduced energy efficiency, which is important for battery-operated or renewable-energy powered edge nodes [6].

Several solutions have been proposed to mitigate memory waste from keep-alive. Existing edge FaaS work jointly controls keep-alive strategies and the distribution of requests to edge nodes [7]. Next, we consider solutions that directly reduce the memory usage of idle sandboxes, independently of request scheduling, which increases their applicability. Medes [8] periodically scans and merges similar memory in idle sandboxes. CodeCrunch [9] compresses functions during their keep-alive period. Such merging and compression operations are computationally expensive, making them unsuitable for edge nodes with low computing power. For example, Medes and CodeCrunch incur up to 133% of CPU overhead (Section III-B) on a Raspberry Pi 5, a typical edge node [10, 11]. Thus, these solutions degrade the processing power of the target node and consequently affect function latencies (Section III-B). Offloading solutions, such as FaaSMem [3], move idle memory to dedicated memory bank nodes via RDMA, which is a feature typically unavailable on edge nodes. In summary, due to the low resource characteristics of edge nodes, existing approaches to directly limiting keep-alive memory waste are either impractical or impose high resource overheads that degrade function latencies.

Introducing ERUN. In this paper, we aim to design an optimal memory usage mechanism to reduce keep-alive memory waste without affecting function latencies, while remaining well suited for low-resource edge nodes. To this end, we introduce the concept of *Extensible RUNtimes* (ERUNs). Unlike standard runtimes, ERUNs provide two operations, *Shrink* and *Expand*, for managing their memory footprint. Briefly, the *Shrink* operation frees the memory regions associated with all
the functions' loaded libraries and stores metadata regarding the discarded libraries in memory (Section IV). The *Expand* operation uses this metadata to restore the previously discarded libraries when a function request arrives. To avoid reloading the libraries from disk, ERUN relies on an in-memory store of libraries, where only one instance of each discarded library is stored and maintained across all runtimes.

We leverage ERUN to reduce the memory usage of idle sandboxes in FaaS platforms. We replace traditional runtimes with ERUNs and augment FaaS worker nodes (nodes that run functions) to trigger a sandbox *Shrink* when the sandbox becomes idle (after garbage collection-hereafter denoted GC). When the node receives a function request, the node triggers a sandbox *Expand* before launching the target function. With this mechanism, the FaaS platform can optimize the server's memory usage without any need for offloading and with minimal impact on function latencies.

**Results obtained with ERUN.** We built an ERUN prototype by lightly augmenting CPython v3.13, a widely used language runtime in FaaS [12], and Lean OpenWhisk v2.0.0 [13], a popular FaaS framework for edge serverless infrastructures. We evaluated the augmented FaaS framework with 10 functions from the SEBS serverless suite [14] and real-world production FaaS traces from Alibaba Cloud [15]. Our evaluation shows several key results. Firstly, ERUN-augmented FaaS platforms reduce idle sandboxes' memory usage by up to 23.13× compared to vanilla keep-alive policies, with an overhead on function latencies ≤ 2%, leading to 1.38× better warm-start ratios. Secondly, ERUN-augmented FaaS platforms incur a CPU overhead ≤ 11.7%, leading to an overhead of ≤ 2% on the energy usage of edge nodes. Lastly, in an edge cluster of 10 nodes, ERUN saves up to 48.91 GB of memory from 80 GB of cluster memory.

**Contributions.** We make the following contributions:

* an analysis of the effects of idle sandboxes on the memory usage of FaaS platforms,

* the design of ERUNs, runtimes that can rapidly shrink their memory usage and restore required libraries to resume processing when required,

* the implementation and evaluation of an open-source ERUN prototype that shows significant memory savings and improved warm-start performance with a minimal overhead on function latencies and energy usage.

## II. BACKGROUND: SANDBOXES LIFETIME STATES

FaaS allows users to trigger the execution of functions in response to a specific event. When an event is captured by the FaaS platform gateway, a node of the FaaS provider is chosen to host the corresponding function. A new sandbox is created to run the function if no ready sandbox is available on the chosen node. Otherwise, a ready sandbox is reused. The user specifies the memory available to a sandbox. Major FaaS platforms allocate a given CPU share to a function sandbox depending on the requested memory size specified by the user.

<figure><img src="image_2.png" /><figcaption>Fig. 1: Sandbox states during their lifetime with events that trigger state switching. Idle-c corresponds to an idle sandbox where no function has been launched, and Idle-t corresponds to an idle sandbox where a function has already run.</figcaption></figure>

As shown in Figure 1, sandboxes can have four states in a FaaS platform, which we denote as *initialized*, *running*, *idle-clean* (*idle-c*), and *idle-tainted* (*idle-t*).

**Initialized state.** This is the state of the sandbox after its creation. A sandbox is created either to handle an incoming function request when no sandbox is available, or to have a spare instance for a specific function. Keeping spare instances is a common feature supported by FaaS platforms to mitigate cold starts (e.g., AWS Lambda Provisioned Concurrency); we call this feature the *premium* option. Independently of the sandbox nature, the creation of a new sandbox involves the initialization of several components. As shown in Figure 2, during initialization, the language runtime is initialized, followed by the loading in the sandbox memory of the libraries required by the FaaS platform software running in the sandbox. We refer to these as platform-specific libraries (hereafter denoted PSL). Concretely, the FaaS platform typically runs a proxy in each sandbox that listens to incoming function trigger requests; an example is the *ActionLoop* proxy in Lean OpenWhisk. In this case, the libraries required for the proxy to run are the PSL.

**Running state.** This state corresponds to the sandbox running a function. When a function runs in a sandbox, as shown in Figure 2, the required libraries by the function are loaded into memory. We refer to the required libraries by the running function as function-specific libraries (hereafter denoted FSL).

**Idle-c state.** This state, which stands for *idle-clean*, corresponds to the sandbox being idle and awaiting a function for the first time. This happens when users subscribe to a FaaS service that ensures that there is always a spare sandbox awaiting their functions. When the corresponding sandbox awaits a function for the first time, its memory layout is similar to an initialized state. An *idle-c* sandbox is paused, thus, its associated vCPUs are removed from the node's CPUs run queues to prevent interference with active sandboxes [16, 17]. As a result, an *idle-c* sandbox memory contains the language runtime and the PSL, as shown in Figure 2.

**Idle-t state.** This state, which stands for *idle-tainted*, corresponds to the sandbox being idle after running a function. When a function finishes its execution, the sandbox becomes idle and paused. As a result, an *idle-t* sandbox memory contains the language runtime, the PSL, and the FSL of the previously exited function, as shown in Figure 2.
<figure><img src="image_3.png" /><figcaption>Fig. 2: Overview of the memory content of a sandbox in three different states: initialized, running a function, and idle. The squares represent objects created during function execution.</figcaption></figure>

Even though idle-{c,t} sandboxes do not process any function, they still hold memory regarding their language runtime, FSL or PSL. The memory regions' idle sandboxes cannot be discarded without impacting function startup times. A recent solution, Desiccant [18], proposes to reduce idle sandbox memory usage by applying tailored GC to reclaim garbage objects and free up memory. GC affects objects created during the function's execution and does not concern FSL or PSL, which still remain in memory. Next, we show that there is still room to further reduce memory usage despite GC solutions.

### III. MOTIVATION: GOING BEYOND GC FOR idle
SANDBOXES MEMORY

#### A. Memory waste at the scale of a function

We design the following experiment to show the potential of going beyond GC-like solutions for idle sandboxes' memory. **Experiment description.** By leveraging real-world FaaS traces from Alibaba Cloud [15]<fnref n="1" />, we simulate function triggers on a local edge FaaS platform powered by Lean Openwhisk [13, 22], a mainstream edge FaaS framework. We use Lean Openwhisk as it provides efficient function trigger mechanisms [23], implements keep-alive, and supports several function runtimes compared to other edge FaaS frameworks, such as TinyFaaS [24] or Sledge [25]. With Lean Openwhisk, the sandboxes are containers. We simulate four random function traces and associate each with a specific function. For each function, we run a 20-minute simulation from the associated trace. We consider two custom Python functions, image resize and video processing. The image resize function takes an input image and resizes it to a 480x480 pixel image; meanwhile, the video processing function trims a video to keep only half of it. The inputs and outputs are downloaded and uploaded to an Amazon S3 bucket. The input image is 5 MB, and the input video is a 10min 720P resolution video of 321 MB. For each experiment, we record the memory used by the created sandboxes during the experiment and the epochs at which the sandboxes change states, i.e., from running to idle-t and idle-t to running. Our functions do not use premium options to reduce their cold starts. Thus, the runtimes created cannot reach the idle-c state (Section II). Each sandbox has a keep-alive period of 10 minutes, a typical period used

<figure><img src="image_4.png" /><figcaption>Fig. 3: Memory usage of function sandboxes over time, including the memory usage when the sandbox is idle and garbage collected (in black), demonstrating the opportunity of optimizing memory during idle periods. We also plot the maximum allocated memory to a sandbox and its base memory, i.e., the memory usage of the sandbox in the initialized state.</figcaption></figure>

<table><caption>TABLE I: Average memory usage of function sandboxes when they are in their different states: init (sandbox initialized), running, idle-t, and idle-t+GC (idle-t but garbage collection has been applied). We observe that even with garbage collection, there is room for memory reduction relative to the init state.</caption><thead><tr><th></th><th>init</th><th>running</th><th>idle-t</th><th>idle-t+GC</th></tr></thead><tbody><tr><td>videoS3</td><td>5.8 MB</td><td>275 MB</td><td>120 MB</td><td>92 MB</td></tr><tr><td>imgS3</td><td>5.8 MB</td><td>150 MB</td><td>48 MB</td><td>40 MB</td></tr></tbody></table>

in production FaaS platforms [26]. We consider two scenarios regarding the sandbox: the instance is idle after the function finishes its execution (the standard scenario), and the second is where GC is applied to the sandbox before pausing it. We reimplement the same principle described by Desiccant [18] to achieve garbage collection on the sandboxes.

Figure 3 plots for each function the memory usage progress of a randomly selected sandbox used to host the corresponding function, the memory allocated to the sandbox, and the memory usage of the initialized sandbox (idle-c), i.e., the memory usage of the sandbox when no function started running. Regarding memory usage, we plot in black the regions where the sandbox is idle, i.e., a function finished its execution, and the sandbox awaits another function trigger. Additionally, Table I reports the average memory usage of our sandboxes when the functions are running, idle without GC, idle with GC, and the associated base image. We note that, independently of the function, the sandbox's memory usage in the initialized state is 5.8 MB, corresponding to the Lean Openwhisk Python v3.12 image.

**Observations and idle memory potential.** Figure 3 and Table I allow us to make three major observations. Firstly, sandboxes have several periods for all functions where they are idle, concretely up to 76% of the time. This observation is similar to orthogonal studies showing that a significant fraction of sandboxes can pass at least 50% of their lifetime idle [27]. Secondly, during the idle-t periods, the sandboxes retain memory significantly higher than the memory used by the initialized/idle-c sandbox, even after GC. The initialized sandboxes correspond to a runtime with only PSL;

<footnote n="1">¹As no publicly available edge FaaS traces exist, we use several cloud FaaS traces as previous works do [19–21]</footnote>
meanwhile, the idle+GC sandboxes runtimes' contain the FSL and FSL of the function running before entering the idle state. Concretely, idle-t sandboxes retain between 12.5x and 20.1x more memory than their corresponding idle-c sandboxes, up to 100MB. This retained memory is wasted during idle periods since no process can use this memory. Thirdly, even when garbage collection is applied on the idle sandboxes, they retain between 7.5x and 12.5x more memory than idle-c sandboxes. This last observation shows the opportunity to reclaim more memory from idle sandboxes.

Reclaiming more memory from idle sandboxes leads to two critical benefits for the FaaS platform. First, reclaiming more memory allows the servers running functions to host more functions. Second, servers can cache more function instances and reduce the number of cold starts that hamper function end-to-end latency, as shown by previous works [3, 18, 28].

## B. Existing work limitations for edge FaaS

Previous research tackles memory reduction of idle runtimes in FaaS but targets high-end, production-grade servers, falling short of covering edge environments. This research can be grouped into memory merging, offloading, and compression. **Memory merging.** Memory merging techniques propose periodically scanning the memory of all runtimes on each node, with a configurable granularity, to identify common memory regions. Then, the common regions are merged and moved to a remote node. When a runtime needs to access a memory region marked by memory merging, this leads to remote memory access. For example, Medes [8] leverages memory merging to create a new runtime state called dedup state, which is a stripped state where the similar memory regions of the runtime with other runtimes are removed and stored on a server node accessible via RDMA. The dedup state speeds function initialization and reduces the memory usage of the runtimes on the server nodes. However, these solutions incur high CPU overhead for edge environments and cannot be entirely functional as there is no RDMA support on edge nodes such as Raspberry PIs. Concretely, on a Raspberry PI 5 with a quad-core Cortex-A76 CPU at 2.4 GHz (detailed specification in Section V), we observe that the periodic scanning and common regions identification of Medes on 10 image-recognition (Table III) functions, which amount to an idle memory size of ≈ 4GB, incurs 101 – 115% of CPU usage across all cores. Thus, one core is hogged, limiting the already low processing power.

**Memory offloading.** Memory offloading techniques share some design with memory merge techniques. Concretely, these techniques offload runtime memory to a remote node accessible via RDMA. The difference lies in which memory regions are offloaded. For example, FaaSMem [3] focuses on identifying runtime memory pages that can be moved to a remote node without impacting function latency. FaaSMem segments the memory of a runtime into three regions: init, runtime, and exec, which correspond to the different stages of a function execution. It continuously monitors the runtimes' memory (by checking their page access bits), constructs a function memory access trace pattern to classify each region,

and offloads pages with a low access rate to reduce memory usage and minimize remote accesses. Consequently, FaaSMem reduces the memory footprint of functions' runtimes. However, these approaches still rely on RDMA and rely heavily on continuous profiling of runtimes, which incurs up to 109% – 123% of CPU usage on a Raspberry PI 5 for 10 image-recognition functions. This result means these solutions have processing power limitations similar to memory merging techniques.

Additionally, the efficiency of memory merge and offloading techniques heavily depends on parameter tuning, such as tuning the scan chunk size and address space layout randomization (ASLR) for Medes or tuning the periodic analysis of runtime's memory access patterns for FaaSMem. Note that we use mpstat to sample CPU usage per core every 100ms. Regarding FaaSMem and Medes, we use the 10s periodic analysis described in their paper, a 64B chunk size for page scanning, and ASLR is activated.

**Memory compression.** Memory compression techniques apply in-memory function compression to reduce memory pressure. An example is CodeCrunch [9] that selectively chooses functions to compress their memory, considering the decompression time. CodeCrunch uses the lz4 compression algorithm and sequential random embedding (SRE) [29], which incur 128–133% CPU overhead for compressing and decompressing 10 image-recognition functions on a Raspberry Pi 5. Furthermore, such approaches require careful tuning of parameters such as compression ratio or compression/decompression speed. Consequently, memory compression on edge devices suffers from the same limitations as memory merge and offloading techniques regarding the available processing power.

Table II presents an overview of the limitations of existing techniques for memory savings in idle runtimes. The analysis in this section shows a clear opportunity to optimize wasted memory and the limitations of existing techniques for low-resource nodes encountered in edge environments. To achieve efficient memory savings of idle runtimes for low-resource nodes, we introduce extensible runtimes (ERUNs).

<table><caption>TABLE II: Summary of existing approaches for memory savings in idle runtimes within edge environments.</caption><thead><tr><th></th><th>Memory Merge (Medes [8])</th><th>Memory Offloading (FaaSMem [3])</th><th>Memory Compression (CodeCrunch [9])</th></tr></thead><tbody><tr><td>CPU overhead on Raspberry Pi 5</td><td>101–115%</td><td>109–123%</td><td>128–133%</td></tr><tr><td>No Parameter tuning required</td><td>※</td><td>※</td><td>✓</td></tr><tr><td>No Continuous monitoring</td><td>※</td><td>※</td><td>✓</td></tr><tr><td>No special hardware requirement</td><td>※(RDMA support)</td><td>※(RDMA support)</td><td>✓</td></tr></tbody></table>

## IV. ERUN: Extensible RUNtimes

Extensible RUNtimes (ERUNs) are augmented runtimes that provide flexible memory usage depending on the runtime state. The key idea behind ERUN is to reduce memory usage when the runtime is idle without affecting the performance when exiting the idle state. ERUN leverages the observation that an idle runtime memory contains unnecessary loaded
<figure><img src="image_5.png" /><figcaption>Fig. 4: Entities created or loaded in memory during a library import. We consider for illustration a generic language with `.ext` for its files/bytecode extension.</figcaption></figure>

libraries during the idle phase. Consequently, discarding the corresponding loaded libraries could reduce the memory usage of an idle runtime. Later, once the runtime exits the idle state, the discarded libraries are reloaded (loaded into the runtime memory space). In the FaaS context, the loaded libraries correspond to the FSL (Section II), unloaded when the runtime is idle and reloaded when exiting the idle state.

### A. Challenges and design overview.

The ERUN design must consider two major challenges to achieve correctness and performance for FaaS sandboxes.

#### Challenge 1: Libraries’ reloading time.
The first challenge concerns libraries’ reloading time, which should be fast enough not to hamper runtime execution when exiting from idle states. To illustrate the problem, we evaluate the loading time of the 20 most downloaded Python packages, as of September 2025 (retrieved on https://pypistats.org/top), on the same testbed described in Section V. The loading times are in the interval [0.1, 330]ms. These results are on par with similar studies on packages’ loading times [30]. Since the execution time of several FaaS functions is less than 60s [27], naively reloading libraries when exiting the idle state can hamper functions’ execution time (knowing that there can be several libraries to reload).

#### Challenge 2: Stateful library objects
As depicted in Figure 4, loading a library triggers the loading of three different types of entities: the objects that represent the library in the runtime, the different associated shared objects needed by the library (e.g., `.so` files) and some source files of the library. For some libraries, the object can maintain a state (attributes of the object). Thus, unloading and reloading libraries with ERUN should consider the libraries’ potential stateful nature to ensure the corresponding objects’ correctness.

#### Design overview.
Considering the aforementioned challenges, ERUN augments existing runtimes by introducing two operations: *shrink* and *expand*. The *shrink* operation reduces the memory usage of the runtime by discarding the loaded libraries; meanwhile, the *expand* operation reloads the previously discarded libraries. In the context of FaaS, the discarded libraries only concern the FSL since other loaded libraries are necessary for receiving and parsing signals from FaaS platform components. Consequently, as depicted in Figure 5, when the

<figure><img src="image_6.png" /><figcaption>Fig. 5: Sandbox lifecycles in a FaaS platform with ERUN. One additional state, *shrunk*, and two new operations to change from one state to another augment the initial lifecycle. ERUN does not require modifying the FaaS platform’s existing trigger systems to trigger the *shrink* and *expand* operations.</figcaption></figure>

<table><caption>**Algorithm 1:** ERUN shrink operation pseudocode</caption><tr><td>/* Get loaded and builtin librairies</td><td>*/</td></tr><tr><td>1 allLibs = getLoadedLibraries()</td><td></td></tr><tr><td>2 builtinLibs = getBuiltInLibraries()</td><td></td></tr><tr><td>3 shrinkLibs = []</td><td></td></tr><tr><td>/* Filter out the builtin libraries</td><td>*/</td></tr><tr><td>4 for each lib in allLibs do</td><td></td></tr><tr><td>5 if lib in builtinLibs then</td><td></td></tr><tr><td>6 allLibs.remove/lib)</td><td></td></tr><tr><td>/* Unload libs and update shrinkLibs</td><td>*/</td></tr><tr><td>7 for each lib in allLibs do</td><td></td></tr><tr><td>/* Retrieve loaded source files and shared objects of each library</td><td>*/</td></tr><tr><td>8 sourceFiles = loadedSourceFiles/lib)</td><td></td></tr><tr><td>9 shObjs = loadedShObjs/lib)</td><td></td></tr><tr><td>10 sMemRefs = []</td><td></td></tr><tr><td>11 shObjsMemRefs = []</td><td></td></tr><tr><td>/* Get memory references of the loaded source files</td><td>*/</td></tr><tr><td>12 for s in sourceFiles do</td><td></td></tr><tr><td>13 sMemRefs.add(getReference(s))</td><td></td></tr><tr><td>/* Get memory references of the loaded shared objects</td><td>*/</td></tr><tr><td>14 for shObj in shObjs do</td><td></td></tr><tr><td>15 shObjsMemRefs.add(getReference(shObj))</td><td></td></tr><tr><td>/* Unload library and save metadata to shrinkLibs */</td><td></td></tr><tr><td>16 unload/lib)</td><td></td></tr><tr><td>17 shrinkLibs.add/lib, sMemRefs, shObjsMemRefs)</td><td></td></tr></table>

FaaS platform pauses a sandbox, the corresponding ERUN runtime traps the pause signal and triggers the *shrink* operation before pausing the runtime. Later, upon resuming the sandbox, the ERUN detects it has been *shrunk* and triggers the *expand* operation before running the corresponding function. A direct advantage of the aforementioned workflow is that it does not require updating the FaaS platform’s existing trigger mechanisms as ERUN traps and infers the corresponding triggers to launch the *shrink* and *expand* operations, respectively. ERUN is an opportunistic solution requiring minimal modifications (as we will see in the following sections) and is most effective when functions rely on similar libraries.

In the next sections, we provide details on the two operations: *shrink* and *expand*, and position ERUN relative to other approaches that target the reduction of FaaS memory usage.
<figure><img src="image_7.png" /><figcaption>Fig. 6: The shrink operation of an ERUN in the FaaS context. The *shrinker* unloads FSL (corresponding to the non-built-in libraries loaded by the user function) and stores related metadata in the *shrinkLibs*.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 7: The expand operation of an ERUN in the FaaS context. The *expander* loads FSL (corresponding to the non-built-in libraries loaded by the user function) from the *singleLibStore* into the runtime's memory.</figcaption></figure>

## B. ERUN *shrink* operation

The *shrink* of an ERUN is the operation that reduces the memory usage. Algorithm 1 presents the steps of the *shrink* algorithm performed by a module called *shrinker*. When a *shrink* is triggered, the *shrinker* module scans the list of all imported libraries and filters out the built-in runtime libraries. The built-in libraries can be inferred from the runtime, which eases the filtering task. Aside from the runtime's built-in libraries, other libraries can also be specified to be left out, such as in FaaS, where some libraries are necessary to process incoming function requests rapidly. For each library in the definitive library list, the *shrinker* unloads it from the runtime memory address space. It achieves this by unloading the imported source files from memory and calling the OS's shared object linker to unload the shared objects. Before the unloads, the *shrinker* keeps the memory references (virtual addresses) of each unloaded element. To cope with Challenge 2, the objects corresponding to each library are not unloaded and kept in memory. Once a library is successfully unloaded, the *shrinker* stores its name, the path of the deleted source files, the path of the shared objects, and the memory references of each deleted element in a metadata dictionary named *shrinkLibs*. The *shrinkLibs* will be queried during the *expand* operation.

Applied to the FaaS context, the *shrinker* will unload the FSL from the runtime memory address space and populate the *shrinkLibs* with the list of FSL as depicted in Figure 6.

## C. ERUN *expand* operation

The *expand* of an ERUN is the operation that reloads the libraries discarded during a *shrink*. When the *expand* is triggered, a module named the *expander* looks into all keys of the *shrinkLibs*. For each library in the *shrinkLibs*, the *expander* reloads the library by corresponding each reloaded element to the corresponding memory reference. Simply reloading the libraries that live on the storage device can take several milliseconds, which can be detrimental to functions in the FaaS context (Challenge 1). We propose a fast-loading approach, *lload* (for light load), to speed up the reload.

As shown in Figure 7, the key idea of *lload* is to reload the discarded libraries from memory instead of the hard drive. With *lload*, we maintain a memory store, named *singleLib-Store*, that contains an instance of loaded libraries across runtimes. Concretely, at the end of an ERUN *shrink*, we check if the discarded libraries exist in the *singleLibStore*. If no library instance is present in memory, we store it (this operation is performed before exiting the *shrink* handler). This ensures only one copy of discarded libraries across all runtimes. The runtimes cannot save a new library directly in *singleLibStore* for security reasons. Thus, they just write in a simple memory-mapped file, its discarded libraries, and a process on the host checks these memory-mapped files to manage the *singleLibStore*. Then, when reloading a library during an *expand*, we create a copy in the runtime address space. The aforementioned process also maintains, for each library in the *singleLibStore*, the number of runtimes that may need its copy during an *expand* and discards the library from the *singleLibStore* if it reaches 0. Since only one instance of each library is maintained in the *singleLibStore*, the cost of maintaining each library remains constant independently of the number of dependent runtimes. We make the design choice of keeping the *singleLibStore* on each server to reduce access costs and overhead on functions compared to other approaches that rely on an external storage server (Section III-B). The *lload* mechanism differs from runtime memory sharing like SOCK [30], as each runtime has its own copy of its library during execution because functions are executed in sandboxes.

ERUN remains relevant even if there are not many distinct functions sharing some libraries. This is because one function can lead to several idle sandboxes due to several invocations per minute [31], leading to memory savings opportunities.

## V. EVALUATION

We evaluate ERUN to assess its benefits. Concretely, we aim to answer the following questions:

* $Q_1$: What is the memory impact of ERUN?

* $Q_2$: What is the latency impact of ERUN on functions?

* $Q_3$: What is the CPU overhead incurred by an edge node?

* $Q_4$: What is the memory usage reduction of ERUN on real-world traces on an edge cluster?

* $Q_5$: What is the energy usage impact of ERUN on a typical edge node?

* $Q_6$: What is the improvement of ERUN regarding warm-start occurrences on real-world traces on an edge cluster?
**Prototypes implementation details.** We design a Python prototype of ERUN by modifying the CPython 3.13 runtime. Python is one of the most dominant runtime supported by FaaS platforms [12]. For simplicity, we will call our prototype ERUN in the rest of the section. We leverage the `globals()` and `sys.builtin_module_names` functions to get the loaded and built-in libraries, respectively. We implement our `singleLibStore` as a memory-mapped directory mounted as read-only in the sandboxes. For the `expand` operation, we implement a new import hook that fetches the libraries from the `singleLibStore`. We also augment the Lean Openwhisk framework, a mainstream FaaS framework tailored for edge environments that runs container functions. The main modifications in Openwhisk concern the functions called when pausing and unpausing containers after terminating a function execution and receiving a function request, respectively. Our prototype introduces 502 lines of code (LOCs) to the CPython runtime and 147 LOCs to the Openwhisk framework and is available at github.com/djobii2078/swiftruntimes. With our `singleLibStore` as a read-only, memory-mapped directory in the sandboxes, integration into a running deployment is straightforward, and the small number of lines of code shows that the changes are easily incorporated.

**Testbed, methodology, and baseline.** We performed our evaluations on a Raspberry Pi 5, with the following characteristics: 8GB memory with a Broadcom BCM2712 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU, 1Gbit/s Realtek RTL8111H NIC, and 1TB M.2 NVMe for our execution nodes (running functions). We use a server with 2\*Intel® Xeon® Gold 6136 Processor, and a MT27520 ConnectX-3 Pro 10Gbits/s network card as our function request generator node. We trigger the functions with the Lean Openwhisk framework. We use the default CPU governor *schedutil*.

For our workloads, we use the Python functions of the macro-benchmarks from the SEBS serverless suite [14] whose characteristics are described in Table III. Unless otherwise specified, each of our experiments is performed 10×, which is enough to achieve 95% confidence intervals $\le 3\%$.

<table><caption>TABLE III: Functions used in our evaluation (SEBS [14]). For each, we show a short description, required libraries, sandbox idle memory after GC (MB), and average execution time (ms).</caption><thead><tr><th>Function</th><th>Description</th><th>Libraries</th><th>Idle Mem (MB)</th><th>Avg. Time (ms)</th></tr></thead><tbody><tr><td>dynamic-html</td><td>Generates 2 KB HTML page</td><td>jinja2</td><td>42</td><td>92</td></tr><tr><td>uploader</td><td>Uploads 2 MB image to S3</td><td>boto3</td><td>42</td><td>143</td></tr><tr><td>thumbnailer</td><td>Creates 480x480 thumbnail</td><td>Pillow, boto3</td><td>45</td><td>205</td></tr><tr><td>video-processing</td><td>Watermarks 50 MB video</td><td>ffmpeg, boto3</td><td>59</td><td>1821</td></tr><tr><td>compression</td><td>Compresses 10×2 MB files</td><td>boto3</td><td>43</td><td>610</td></tr><tr><td>image-recognition</td><td>Classifies 300 KB image</td><td>pytorch</td><td>367</td><td>1377</td></tr><tr><td>graph-pagerank</td><td>PageRank on 5000-node graph</td><td>igraph</td><td>54</td><td>1422</td></tr><tr><td>graph-mst</td><td>Minimum spanning tree 5000 nodes</td><td>igraph</td><td>53</td><td>1993</td></tr><tr><td>graph-bfs</td><td>BFS on 5000-node graph</td><td>igraph</td><td>54</td><td>1820</td></tr><tr><td>dna-visualisation</td><td>2D DNA sequence visualization</td><td>squiggle, boto3</td><td>71</td><td>329</td></tr></tbody></table>

## A. ERUN impact on function's memory and execution time

This section aims at answering $Q_1$ and $Q_2$.

**Experimental procedure.** We launch the execution of 10 similar functions and trigger garbage collection before pausing their runtimes. After 30s, we retrigger the execution of the

10 functions. This corresponds to our baseline, denoted as GC. We then repeat the experiment while using ERUN as our runtime. For each experiment, we record the average memory saved during the idle period of the sandboxes and their execution times during the second execution round.

**Memory savings results.** Figure 8 reports for each function (group of 10 functions) the average memory savings improvement achieved by ERUN and GC across each function. We also plot the IDEAL solution, which is the theoretically desired saving that every solution aims at reaching (i.e., no memory waste). Concretely, IDEAL corresponds to the best imaginary scenario, where an idle sandbox has the same memory footprint as the base image with no loaded library (in our case, 5.8MB - as stated in Section III-A), no impact on the execution time upon resume, and no overhead on CPU usage. The higher the memory savings, the better. We observe that ERUN comes the closest to the IDEAL results and achieves savings between 3.15× (compression function, from 43.5 → 13.8 MB) to 23.13× (image recognition function, from 367.8 → 15.9 MB). These savings originate from unloading the function's non-built-in libraries before pausing the function's sandbox. Thus, even memory left out by the GC is unloaded, leading to reduced memory usage. Note that even if ERUN keeps one instance of the unloaded libraries in memory, this storage cost is amortized as the number of functions that use that library increases on the execution node.

**Latency results.** Figure 9 reports, for each function (group of 10 functions), the average execution time across each function and for GC and ERUN. We also plot the IDEAL solution corresponding to the execution with no overhead on functions' execution time. The lower the execution time, the better. We observe that ERUN incurs an overhead on function execution time between 1.004% (image recognition, 1821.4 → 1828.3s) up to 1.015% (dynamic HTML, 92.4 → 93.8ms) compared to the GC approach. This overhead comes from the *expand* operation required before resuming the execution of a function. Overall, the *expand* of our ERUN incurs an overhead of at most 6.9ms. Meanwhile, the *shrink* that occurs before pausing a runtime takes at most 993µs. This is a direct consequence of the ERUN *lload* mechanism that keeps one instance of discarded libraries in memory instead of a remote node. This allows the overhead on functions' execution time to be less than 1.1%, which is a very low overhead.

## B. ERUN overhead on edge node resources

This section aims at answering $Q_3$. Note that we do not evaluate network overhead since ERUN does not incur any such overhead; the *shrink* and *expand* operations do not involve network communications.

**Experiment.** To assess the CPU overhead incurred by ERUN and the baselines, we repeat the same experiment as V-A for a group of 10 similar functions. We record the CPU usage and memory usage during the entire experiment. Concretely, we assess the overhead of ERUN *shrink* and *expand* operations.

**Results.** Figure 10 reports the average CPU usage overhead of the function execution node for each function and the
<figure><img src="image_9.png" /><figcaption>Fig. 8: Memory usage improvements brought by GC and ERUN. ERUN achieves up to 23.13× memory savings.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Fig. 9: Overhead on functions' execution time with GC and ERUN. ERUN incurs less than 1.1% overhead.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 10: CPU usage all cores on the edge node with GC and ERUN, with 10 instances of each function.</figcaption></figure>

different configurations. The overhead is computed with respect to the CPU usage of a vanilla setting, i.e., no memory waste reduction mechanism. We also plot the IDEAL solution, corresponding to no CPU overhead on the node. We observe that ERUN incurs an average additional CPU usage (compared to GC) between 4.12% and 11.7% across all cores. This is significantly lower than memory merging, offloading, or compression techniques that incur overhead over 100% across all cores (Section III-B). This is the direct consequence of not relying on computationally expensive operations such as page scanning or compression. We believe that the ERUN CPU overhead is acceptable given the memory savings.

### C. ERUN savings and energy usage on real-world traces.

This section aims at answering $Q_4$ and $Q_5$.

**Experimental procedure.** To assess the performance of ERUN on real-world traces on an edge cluster, we leverage Alibaba FaaS public traces [15]. We use public cloud traces due to the current unavailability of edge FaaS trace datasets, which is consistent with prior edge FaaS research (e.g., [20, 21]). We select a random trace (Id: 431387eb7262e1cfc79b125eb8a67c60 in the trace) and trigger function execution following the epochs in the trace atop a cluster composed of 10 execution edge nodes, thus a cluster memory capacity of 80GB. We follow previous work methodology [8] and multiply the inter-arrival rate by 5× due

<figure><img src="image_12.png" /><figcaption>Fig. 11: Cluster memory usage, energy usage, and the image-recognition function execution time on the cluster of 10 edge nodes with a random Alibaba Trace of 30 minutes. Overall, ERUN achieves up to 48.9GB of memory savings (61.13% of the cluster total memory) with an overhead of 1.08% and 1.9% on functions' execution times and energy usage, respectively.</figcaption></figure>

to the low rate in the traces. The function execution requests are dispatched to execution nodes based on the availability of a warm runtime and available memory. We use a keep-alive value of 10 minutes commonly used by mainstream FaaS platforms [26]. We run the experiment for each function with the GC and ERUN approaches. During the experiment, we record the cluster memory usage, energy usage, functions' execution times, and number of cold/warm starts.

**Results.** Due to space constraints, we only report the results for one function, image-recognition, in Figure 11, and discuss overall results in the text. We make three observations. Firstly, on average, the cluster's memory usage is lower with ERUN compared to the GC approach. This is due to the savings achieved by ERUN during the idle periods. Concretely, ERUN achieves in average 15.33GB savings (19.16% of the cluster total memory) and reaches up to 48.91GB (61.13% of the cluster total memory). Secondly, the functions' mean latency overhead of ERUN is 1.04% on average and reaches 1.08% for the 99th percentiles for all functions, compared to GC. Lastly, ERUN incurs only up to 1.9% overhead on the cluster energy usage since ERUN does not introduce computationally expensive operations.

### D. ERUN impact on warm starts.

This section aims at answering $Q_6$.

**Experimental procedure.** We repeat the same experiment as in Section V-C and increase the inter-arrival scale factor from 5× to 20×. We also monitor the warm start ratio and the number of failed triggers due to memory shortage. For each failed request, we relaunch it after 10s.

**Results.** Due to space constraints, we only report the results for one function, the one with the highest memory usage and longest execution time, image-recognition (Table III). However, the observations are on par across other functions. Overall, ERUN achieves a warm start ratio of up to 97.08% with no failed function trigger, meanwhile, the GC approach goes down up to 67.03% with up to 285 failed requests (24.4% of the total function triggers) due to memory shortage. This difference in warm start ratio comes from the fact that since more memory is saved with ERUN during idle sandbox periods, more idle instances can be cached and used to served incoming functions. As the scale factor increases, several
<table><caption>TABLE IV: Failed requests and warm start ratio atop our edge FaaS cluster using the GC approach and ERUN (ours) with different inter-arrival time scale factors.</caption><thead><tr><th>Inter-arrival rate scale</th><th>5x</th><th>10x</th><th>15x</th><th>20x</th></tr></thead><tbody><tr><th colspan="5" style="text-align: center;">Idle-t+GC</th></tr><tr><td>Failed requests (%)</td><td>3.4</td><td>7.8</td><td>17.7</td><td>24.4</td></tr><tr><td>Warm start ratio (%)</td><td>93.7</td><td>88.8</td><td>76.05</td><td>67.03</td></tr><tr><th colspan="5" style="text-align: center;">ERUN (ours)</th></tr><tr><td>Failed requests (%)</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Warm start ratio (%)</td><td>97.08</td><td>96.67</td><td>93.32</td><td>92.72</td></tr></tbody></table>

parallel requests are triggered more frequently, which causes the number of available warm instances to decrease more rapidly, reducing the warm start ratio even for ERUN. Overall, ERUN improves the warm start ratio by 1.38× compared to the GC approach, improving function initialization times.

## VI. DISCUSSION: SECURITY AND OTHER LANGUAGES

The key security issue with ERUN stems from the shared in-memory store, which can lead to corrupted runtimes. The current protection, however, does not allow writes to the shared store and applies COW. We also envision checking the libraries loaded in the store to ensure they originate from trusted sources, or periodically reloading each library to prevent silent corruption, as used in other contexts [32, 33]. We believe ERUN's strategy can be applied to other language runtimes that dynamically load libraries or optimize initialization costs, such as JIT compilation, by hooking into the V8 engine for Node.js or the CLR for C#, for example. The key idea is to identify the libraries' loading path and build a library store to implement "expand/shrink" operations.

## VII. RELATED WORK

Beyond the related approaches examined in Section III-B, some existing work implicitly aims to reduce the memory usage of runtimes in the FaaS context without targeting idle runtimes. OFC [34] predicts the actual memory usage of functions based on their input in order to trim function memory allocations and prevent users from over-provisioning, as users decide the required amount of memory for their functions. Other approaches propose to reduce the memory footprint by carefully sharing sandboxes among functions. Such solutions include RainbowCake [28], which is a hybrid solution between sandbox sharing and caching, Pagarus [35], FaaSCache [36], Sock [30], FlashCube [37], or SEUSS [4]. The idea is to pack several functions into sandboxes to maximize memory usage and leverage techniques such as copy-on-write to prevent inter-function interference. ERUN does not perform container sharing among functions, but can be extended to consider it. Furthermore, container sharing does not remove the need for keep-alive making ERUN applicable in such scenarios.

Other research proposed specialized runtimes, based on WebAssembly, such as FaaSM [38], Shredder [39], and, specifically for edge FaaS, Sledge [25] and WoW [40]. Previous work shows that native runtimes are still faster in some scenarios [23], and WebAssembly runtime support is still limited

by the lack of production-ready features such as networking support in WASI or multi-threading [40, 41]. Moreover, these specialized runtimes are not immune to idle sandbox memory issues if the target FaaS framework employs keep-alive. Thus, the ERUN core idea remains applicable for such runtimes.

## VIII. CONCLUSION

We introduce ERUNs, standing for extensible runtimes, which can rapidly reduce their memory usage during idle periods with a negligible impact on execution time when resuming. We apply ERUN in the context of FaaS in edge environments, where execution nodes have low processing power. Unlike existing memory-optimization solutions, ERUN does not require continuous memory monitoring, parameter tuning, or specific hardware, making it suitable for edge nodes. Our evaluation in edge environments using representative workloads from the SEBS serverless suite and real-world serverless traces from Alibaba shows that ERUN effectively reduces memory usage by up to 23.13×, 1.38× better warm start ratio, and energy usage overhead ≤ 2%.

## IX. ACKNOWLEDGMENTS

We thank the anonymous reviewers for their insightful comments. This work was supported by the French ANR project sGOV (ANR-23-CE25-0007-01).

## REFERENCES

[1] M. S. Aslanpour, A. N. Toosi, C. Cicconetti, B. Javadi, P. Sbarski, D. Taibi, M. Assuncao, S. S. Gill, R. Gaire, and S. Dustdar, "Serverless edge computing: Vision and challenges," in *ACSW '21*.

[2] D. Ustiugov, P. Petrov, M. Kogias, E. Bugnion, and B. Grot, "Benchmarking, analysis, and optimization of serverless function snapshots," in *ASPLOS '21*.

[3] C. Xu, Y. Liu, Z. Li, Q. Chen, H. Zhao, D. Zeng, Q. Peng, X. Wu, H. Zhao, S. Fu, and M. Guo, "Faasmem: Improving memory efficiency of serverless computing with memory pool architecture," in *ASPLOS '24*.

[4] J. Cadden, T. Unger, Y. Awad, H. Dong, O. Krieger, and J. Appavoo, "Seuss: skip redundant paths to make serverless fast," in *EuroSys '20*.

[5] H. Tian, S. Li, A. Wang, W. Wang, T. Wu, and H. Yang, "Owl: Performance-aware scheduling for resource-efficient function-as-a-service," in *SoCC '22*.

[6] M. S. Aslanpour, A. N. Toosi, M. A. Cheema, and R. Gaire, "Energy-aware resource scheduling for serverless edge computing," in *CCGrid '22*.

[7] L. Pan, L. Wang, S. Chen, and F. Liu, "Retention-aware container caching for serverless edge computing," in *INFOCOM '22*.

[8] D. Saxena, T. Ji, A. Singhvi, J. Khalid, and A. Akella, "Memory deduplication for serverless computing with medes," in *EuroSys '22*.

[9] R. Basu Roy, T. Patel, R. Garg, and D. Tiwari, "Code-crunch: Improving serverless performance via function
compression and cost-aware warmup location optimization,” in ASPLOS ’24.

[10] L. Sanabria-Russo, D. Pubill, J. Serra, and C. Verikoukis, “Iot data analytics as a network edge service,” in IEEE INFOCOM 2019 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2019, pp. 969–970.

[11] F. Xhafa, B. Kilic, and P. Krause, “Evaluation of iot stream processing at edge computing layer for semantic data enrichment,” *Future Generation Computer Systems*, vol. 105, pp. 730–736, 2020. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167739X19321296

[12] Datadog, “The state of serverless,” https://www.datadoghq.com/state-of-serverless/.

[13] D. Breitgand, “Lean openwhisk: Open source faas for edge computing,” https://medium.com/openwhisk/lean-openwhisk-open-source-faas-for-edge-computing-fb823c6bbb9b.

[14] M. Copik, G. Kwasniewski, M. Besta, M. Podstawski, and T. Hoefler, “Sebs: A serverless benchmark suite for function-as-a-service computing,” in *Middleware ’21*.

[15] Alibaba, “Alibaba cluster trace program,” https://github.com/alibaba/clusterdata.

[16] D. Mvondo, A. Barbalace, A. Tchana, and G. Muller, “Tell me when you are sleepy and what may wake you up!” in SOCC ’21.

[17] D. Mvondo, F. Taiani, and Y.-D. Bromberg, “Horse: Ultra-low latency workloads on faas platforms,” in *Middleware ’24*, 2024, p. 445–453.

[18] Z. Zhao, M. Wu, H. Chen, and B. Zang, “Characterization and reclamation of frozen garbage in managed faas workloads,” in EuroSys ’24.

[19] C. Cicconetti, M. Conti, and A. Passarella, “Faas execution models for edge applications,” PMC, vol. 86, 2022.

[20] X. Zhang, H. Gu, G. Li, X. He, and H. Tan, “Online function caching in serverless edge,” in ICPADS ’23.

[21] C. Chen, L. Nagel, L. Cui, and F. P. Tso, “S-cache: Function caching for serverless edge computing,” in EdgeSys ’23.

[22] Apache, “Apache: Open source serverless cloud platform,” https://openwhisk.apache.org/.

[23] A. Hall and U. Ramachandran, “An execution model for serverless functions at the edge,” in *Proceedings of the International Conference on Internet of Things Design and Implementation*, 2019.

[24] T. Pfandzelter and D. Bermbach, “Tinyfaas: A lightweight faas platform for edge environments,” in ICFC ’20.

[25] P. K. Gadepalli, S. McBride, G. Peach, L. Cherkasova, and G. Parmer, “Sledge: a serverless-first, light-weight wasm runtime for the edge,” in *Middleware ’20*.

[26] M. Shilkov, “Cold starts in aws lambda,” https://mikhail.io/serverless/coldstarts/aws/.

[27] M. Shahrad, R. Fonseca, I. Goiri, G. Chaudhry, P. Batum, J. Cooke, E. Laureano, C. Tresness, M. Russinovich,

and R. Bianchini, “Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider,” in USENIX ATC ’20.

[28] H. Yu, R. Basu Roy, C. Fontenot, D. Tiwari, J. Li, H. Zhang, H. Wang, and S.-J. Park, “Rainbowcake: Mitigating cold-starts in serverless with layer-wise container caching and sharing,” in ASPLOS ’24.

[29] H. Qian, Y.-Q. Hu, and Y. Yu, “Derivative-free optimization of high-dimensional non-convex functions by sequential random embeddings,” in IJCAI.

[30] E. Oakes, L. Yang, D. Zhou, K. Houck, T. Harter, A. Arpaci-Dusseau, and R. Arpaci-Dusseau, “SOCK: Rapid task provisioning with Serverless-Optimized containers,” in USENIX ATC ’18.

[31] A. Joosen, A. Hassan, M. Asenov, R. Singh, L. Darlow, J. Wang, Q. Deng, and A. Barker, “Serverless cold starts and where to find them,” in EUROSYS, 2025.

[32] K. Yamakita, H. Yamada, and K. Kono, “Phase-based reboot: Reusing operating system execution phases for cheap reboot-based recovery,” in *2011 IEEE/IFIP 41st International Conference on Dependable Systems Networks (DSN)*, 2011, pp. 169–180.

[33] J. Liu, Y. Dai, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “Fast, transparent filesystem microkernel recovery with ananke,” in *23rd USENIX Conference on File and Storage Technologies (FAST 25)*. Santa Clara, CA: USENIX Association, Feb. 2025, pp. 1–18. [Online]. Available: https://www.usenix.org/conference/fast25/presentation/liu-jing

[34] D. Mvondo, M. Bacou, K. Nguetchouang, L. Ngale, S. Pouget, J. Kouam, R. Lachaize, J. Hwang, T. Wood, D. Hagimont, N. De Palma, B. Batchakui, and A. Tchana, “Ofc: an opportunistic caching system for faas platforms,” in EuroSys ’21.

[35] Z. Li, L. Guo, Q. Chen, J. Cheng, C. Xu, D. Zeng, Z. Song, T. Ma, Y. Yang, C. Li, and M. Guo, “Help rather than recycle: Alleviating cold startup in serverless computing through Inter-Function container sharing,” in USENIX ATC ’22.

[36] A. Fuerst and P. Sharma, “Faascache: keeping serverless computing alive with greedy-dual caching,” in ASPLOS ’21, 2021, p. 386–400.

[37] Z. Lin, K.-F. Hsieh, Y. Sun, S. Shin, and H. Lu, “Flashcube: Fast provisioning of serverless functions with streamlined container runtimes,” in PLOS ’21, 2021.

[38] S. Shillaker and P. Pietzuch, “Faasm: Lightweight isolation for efficient stateful serverless computing,” in USENIX ATC ’20.

[39] T. Zhang, D. Xie, F. Li, and R. Stutsman, “Narrowing the gap between serverless and its state with storage functions,” in SoCC ’19.

[40] P. Gackstatter, P. A. Frangoudis, and S. Dustdar, “Pushing serverless to the edge with webassembly runtimes,” in CCGrid ’22.

[41] M. Kolny, “The future of the wasi-threads proposal #48.” https://github.com/WebAssembly/wasi-threads/issues/48.