Runtime Object Lifetime Profiler for Latency Sensitive Big Data Applications
Rodrigo Bruno∗ Duarte Patrício José Simão [email protected] [email protected] [email protected] Systems Group, Department of INESC-ID / IST - Técnico, ULisboa INESC-ID / ISEL, IPL Computer Science, ETH Zurich Portugal Portugal Switzerland Luís Veiga Paulo Ferreira [email protected] [email protected] INESC-ID / IST - Técnico, ULisboa University of Oslo / INESC ID Portugal Norway / Portugal
Abstract GC algorithms allocating objects with similar lifetimes close Latency sensitive services such as credit-card fraud detec- to each other so that the overall fragmentation, GC effort, tion and website targeted advertisement rely on Big Data and application pauses are reduced. ROLP is implemented platforms which run on top of memory managed runtimes, for the OpenJDK 8 and was evaluated with a recently pro- such as the Java Virtual Machine (JVM). These platforms, posed open-source pretenuring collector (NG2C). Results however, suffer from unpredictable and unacceptably high show long tail latencies reductions of up to 51% for Lucene, pause times due to inadequate memory management deci- 85% for GraphChi, and 69% for Cassandra. This is achieved sions (e.g., allocating objects with very different lifetimes with negligible throughput (< 6%) and memory overhead, next to each other, resulting in severe memory fragmen- with no programmer effort, and no source code access. tation). This leads to frequent and long application pause CCS Concepts • Software and its engineering → Mem- times, breaking Service Level Agreements (SLAs). This prob- ory management; Garbage collection; Runtime envi- lem has been previously identified, and results show that ronments; current memory management techniques are ill-suited for applications that hold in memory massive amounts of long- Keywords Big Data, Garbage Collection, Pretenuring, Tail lived objects (which is the case for a wide spectrum of Big Latency, Profiling Data applications). Previous works reduce such application pauses by allocat- 1 Introduction ing objects in off-heap, in special allocation regions/genera- Big Data applications suffer from unpredictable and unac- tions, or by using ultra-low latency Garbage Collectors (GC). ceptably high pause times due to bad memory management However, all these solutions either require a combination of (Garbage Collection) decisions. This is the case of credit- programmer effort and knowledge, source code access, off- card fraud detection or website targeted advertisement, for line profiling (with clear negative impacts on programmer’s example, among others. These systems rely on latency sensi- productivity), or impose a significant impact on application tive Big Data platforms (such as graph-based computing or throughput and/or memory to reduce application pauses. in-memory databases) to answer requests within a limited We propose ROLP, a Runtime Object Lifetime Profiler that amount of time (usually specified in Service Level Agree- profiles application code at runtime and helps pretenuring ments, SLAs). Such pauses in these platforms delay applica- ∗Work done while at INESC-ID / IST - Técnico, ULisboa. tion requests which can easily break SLAs. This latency problem has been previously identified [11, Permission to make digital or hard copies of all or part of this work for 19, 20] and results from a combination of factors. First, Big personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear Data platforms keep in memory large volumes of data. Sec- this notice and the full citation on the first page. Copyrights for components ond, current Garbage Collector (GC) algorithms highly rely of this work owned by others than ACM must be honored. Abstracting with on object copying to compact memory. Third, object copy- credit is permitted. To copy otherwise, or republish, to post on servers or to ing is bound to the physical memory bandwidth which has redistribute to lists, requires prior specific permission and/or a fee. Request been increasing more slowly when compared to the number permissions from [email protected]. of cores and size of the memory available in current com- EuroSys ’19, March 25–28, 2019, Dresden, Germany © 2019 Association for Computing Machinery. modity hardware [3, 10, 13], resulting in memory bandwidth ACM ISBN 978-1-4503-6281-8/19/03...$15.00 being the bottleneck for many parallel applications. In sum, https://doi.org/10.1145/3302424.3303988 although the widely accepted hypothesis that most objects 1 die young [26, 39] is still valid for most platforms, the over- the intensive use of factory methods, common in object ori- head that results from handling the minority of objects that ented languages, that allocate objects used for very different live longer is not negligible and thus, these objects need to use-cases (with different lifetimes). be handled differently. This problem has been described as Profiling information produced by ROLP makes it possible a mismatch between the generational hypothesis and the to instruct the JVM to allocate long-lived objects close to each epochal hypothesis [33]. other, in a separate space, thus avoiding the cost of copying Recent works (more details in Sections 2 and 9) try to them multiple times (which leads to long application pauses). alleviate this high latency problem by taking advantage of ROLP is targeted for long-running cloud applications that programmer’s knowledge. To do so, proposed techniques hold massive amounts of objects in memory for a long time, resort to modifying code through: i) manual refactoring of and have low latency requirements. Target applications and the application code [21], ii) adding code annotations[11, 33], motivation for this work is further explored in Section 2. or iii) static bytecode rewriting [9, 34]. The modified code ROLP is implemented in the OpenJDK 8 HotSpot JVM, one reduces the GC effort by either using off-heap memory,1 of the most widely used industrial JVMs. To take advantage or by redirecting allocations to scope limited allocation re- of the profiling information, ROLP is integrated with NG2C gions2 or generations, leading to reduced GC effort to collect [11], a pretenuring GC (based on Garbage First [16]) that memory. However, these works have several drawbacks as can allocate objects in different allocation spaces. Note that they require: i) the programmer to change application code, any other collector that supports multiple allocation spaces and to know the internals of GC to understand how it can can also be used. be alleviated; ii) source code access, which can be difficult if To the best of our knowledge, ROLP is the first object life- libraries or code inside the Java Development Kit needs to time profiler that can categorize objects in multiple classes be modified; and iii) workloads to be stable and known be- of estimated lifetime, implemented in a production JVM with forehand, since different workloads might lead to completely negligible performance overhead. ROLP supports any ap- different GC overheads. plication that runs on top of the JVM (i.e., it is not limited Our work shares the same main goal with many previous to the Java language) and users can benefit from reduced works (reduce application pauses). However, we propose a application pauses with no programmer effort or any need number of additional goals that allow our solution to avoid for off-line profiling. ROLP builds upon NG2C by providing the drawbacks present in previous solutions. In other words, automatic lifetime information that is used by NG2C to allo- our solution: i) requires no programmer knowledge and ef- cate objects in different memory locations (according to the fort; ii) it works without any access to application source estimated lifetime). ROLP also provides package filters that code, and iii) it copes with unknown/dynamic workloads. can be used to reduce the performance overhead introduced In addition, ROLP has no significant negative impact on by profiling code in large applications. These package filters throughput or on memory usage, and it works as a simple are easier and less error-prone to use when compared to JVM command line flag. hand-placed annotations necessary to use NG2C. As shown Long application pauses caused by GC are mainly due to in the evaluation section (Section 8), when compared to other copying objects during object promotion and compaction. approaches, ROLP can be used to greatly reduce application To reduce such copies, objects with different lifetimes should pause times. be allocated in different spaces, thus reducing fragmenta- tion. To identify such objects with different lifetimes, we 2 Motivation propose ROLP, an object lifetime profiler running inside the This section presents the long pause time problem in current JVM that tracks object allocation and collection. The profiler runtime systems, its importance, and why it cannot be solved has one main goal, to estimate the lifetime of objects based using current GC algorithms and systems. on their allocation context. Using this information, we take advantage the following hypothesis: if a high percentage 2.1 Tail Latency introduced by Garbage Collection of objects allocated through a particular allocation context are long-lived, then it is expected that future objects allo- Partitioning allocated objects by their estimated lifetime cated through the same allocation context will also live for is a fundamental design aspect in current GC design [25]. a long time. In other words, this hypothesis states that an However, due to the high cost of estimating the lifetime of object’s allocation context can be used as an indicator of its objects, most collectors simply rely on the weak generational lifetime [5]. According to our experience, indicators such as hypothesis [39] that states that most objects die young, and the object type do not provide accurate information due to therefore, allocate all objects in the same space and pay the cost of promoting the minority of objects that live longer than most objects. 1Off-heap is a manually managed backing store made available bytheJVM. While this design works well for applications that follow 2Objects’ reachability is limited by the scope of allocation. the generational hypothesis, it leads to long tail latencies for 2 applications that handle many middle to long-lived objects cycles, i.e., the GC cycle is the unit of time. Thus, the age of (as it happens with many Big Data applications [10]). Such la- an object is the number of GCs that an object has survived. tencies come from long copy times (compacting live objects) On the other hand, ROLP defines an allocation context asa that are bound to hardware memory bandwidth. In addition, tuple of: i) an allocation site identifier, which identifies the these copy times will become longer and longer as the num- line of code where the object is allocated, and ii) a thread ber of cores and memory capacity is increasing faster than stack state, which describes the state of the execution stack memory bandwidth in current commodity hardware [10]. upon allocation. Recently proposed GC works [11, 14, 33] try to reduce the overhead of estimating the lifetime of objects. After in- tegrating this new information into the GC, a better object 3.1 Solution Overview partition by lifetime is possible, leading to reduced fragmen- ROLP uses different techniques to answer the proposed ques- tation and thus, reduced latency. However, these techniques tion. First, upon allocation, all objects are marked in their are heavy, error-prone, require source code changes, are lim- header with an allocation context that identifies both the ited to simple workflows, or can only profile code during allocation site (i.e., line of code) and the thread stack state. code warm-up. This topic is discussed in Section 9. As detailed below, ROLP takes advantage of profiling code in- stalled during Just-In-Time (JIT) compilation to accomplish 2.2 Trading Throughput and Memory for Latency this task. To know the age of objects, ROLP tracks both the Other GC implementations such as C4 [37], Shenandoah number of allocated objects, and survivor objects during GC [18], and ZGC 3 solve the latency problem by performing all cycles. This information (number of allocated and survivor GC tasks almost fully concurrent with the mutator (applica- objects) is kept in a global Object Lifetime Distribution table tion threads). These collectors still require copying massive (see Fig. 1). This table maintains the number of objects with a amounts of objects but most copies are done concurrently specific age organized by allocation context. In the following with the mutator. Thus, these GCs incur very short pauses; sections, we describe these techniques in detail. however, the drawback is the application throughput over- head that is caused by the heavy use of both read and write barriers, and the increased memory usage (see results in 3.2 Application Code Instrumentation Section 8.5). ROLP only profiles very frequently executed/hot application On the one hand, current GC algorithms, which heavily code. To that end, we take advantage of the JIT compilation rely on object copying to compact memory inflict unpre- engine in the HotSpot JVM to identify/define hot applica- dictable and unacceptably long tail latencies on applications. tion code. There are two reasons why ROLP only profiles This situation will not improve as memory bandwidth is a hot code. First, installing profiling code has a cost (e.g., for scarce resource, even more with the fast developments on creating unique identifiers for allocation sites) and thus, it the number of cores and memory capacity. On the other makes sense to pay this cost only for application code that hand, concurrent GCs reduce overall GC latency but at a is executed very frequently (note that only a small fraction high throughput and memory cost. of the application code is usually hot). Second, since most of The work now presented, ROLP, is a new solution in the execution time is spent running hot code, not profiling the Throughput-Memory-Latency trade-off as it reduces the code that is not executed frequently (i.e., cold code), does overall latency, with special focus on long tail latency, and not lead to a significant loss of profiling information. inflicts a negligible impact on throughput and memory us- In short, the profiling code (added to the application code age. We envision that this solution is mostly beneficial for during JIT) is responsible for performing the following tasks: long-running cloud platforms that are latency sensitive, as i) update the thread stack state (thread-local value that en- it happens with many Big Data applications. There are addi- codes the state of the execution stack) whenever a new frame tional use-cases for ROLP such as detecting memory leaks is pushed or removed from the stack; ii) increment the num- in applications by reporting object lifetime statistics per al- ber of allocated objects (in the Object Lifetime Distribution location context. Nevertheless, we will not explore use-cases table) for the corresponding allocation context, upon object in this paper however. allocation; and iii) install the allocation context in the ob- ject header (see Fig. 2), upon object allocation. Note that, as 3 Object Lifetime Profiling ROLP does not profile cold methods (i.e., non JIT compiled), ROLP is built to answer one simple question: how long will it does not record lifetime information of all objects. ROLP fo- an object live, based on its allocation context. To answer cuses on profiling the code that is executed more frequently this question, we must first define the notion of time and in the hope of achieving the best trade-off of profiling over- allocation context. On one hand, time is measured in GC head versus performance benefits. The next sections describe each one of these tasks in detail. 3http://openjdk.java.net/projects/zgc 3 Methodm Object Lifetime Distribution is biased locked (i.e., if bit number 3 is set) or if the allocation BCI Bytecode Allocation Context Age Table
Decrement (acm+i+t, ageb) context is corrupted (i.e., it does not correspond to any entry bci0 bc0 ...... Increment (acm+i+t, ageb+1) Increment (acm+i+t, 0) ...... acm+i+t
ageb Threadt Class context which matches the same 32 bits. This is a very rare
... Field0 Survivor Objectb scenario as the upper 32 bits of the object header (which Thread Stack State ... tsst store the pointer to the thread that owns the biased lock) ... FieldN Eden Old Space must match the same exact 32 bit of an allocation context. Figure 1. ROLP Profiling Object Allocation and GC Cycles Using the space dedicated to biased locks means that ROLP looses some profiling information. However, through
Header Bits our experience and based on previous evaluation results, we 64 56 48 40 32 24 16 8 0 argue that: i) the number of biased locked objects in Big Data applications is not significant; ii) data objects are usually Allocation Site Thread Stack State Identity Hash Age not used as locks (and therefore are not biased locked); iii)
Allocation Context Unused Biased-lock Lock not profiling control (non-data) objects does not lead toa significant loss of important information since these control Figure 2. Object Header in HotSpot JVM using ROLP objects are usually small both in size and number. 3.2.3 Allocation Context Tracking 3.2.1 Context of Allocation As already mentioned, the allocation context is a tuple of: i) The number of allocated objects per allocation context is allocation site identifier that identifies a specific line of code, maintained in the Object Lifetime Distribution table (see and ii) thread stack state. The later is necessary to distin- Fig. 1). As depicted, upon each object allocation, the alloca- guish two object allocations that, although using the same tion context acm+i+t is generated by combining both: i) the allocation site identifier (i.e., the same code location), use allocation site identifieras ( m+i), which identifies the specific different call paths to reach the allocation site. This isavery code location where the allocation is taking place (method common scenario when object allocation and initialization m, bytecode index i), and ii) the thread stack state sst, which is delegated to libraries or frameworks. identifies the state of the execution stack of the thread t ROLP uses arithmetic operations (sum and subtraction) (which is allocating the object). The resulting allocation con- to incrementally update the 16 bit thread stack state of each text is installed in the header of the newly allocated object. thread. Thus, before each method call, the thread-local stack state is incremented with a unique method call identifier. 3.2.2 Marking Objects with the Allocation Context The same value is subtracted when the execution exits the ROLP associates each allocated object with an allocation method. context by storing the corresponding allocation context in This technique relies on the following. First, for allocation the object’s header. Note that adding more information to tracking purposes, it suffices that the thread stack state dif- application objects (for example, increasing the header size) ferentiates two different call paths. Hence, the order ofthe is undesirable as it increases the memory footprint by adding method calls that compose each call path is not required to extra bytes to every object. Therefore, ROLP reuses spare be contained in the thread stack state. Second, this state must bits that already exist in an object header. be incrementally maintained as the application execution Figure 2 presents the 64-bit object header used for each goes through the call path and enters and leaves methods. object in the HotSpot JVM. As depicted, for each object, However, adding two arithmetic operations for each me- ROLP installs the corresponding allocation context in the thod call can lead to throughput penalties as method calls upper 32 bits of the 64-bit header. These 32 bits are currently are very common in high level languages. To cope with this only used when an object is biased locked towards a specific problem, ROLP is able to dynamically turn on and off the 4 thread, and using them does not compromise the semantics execution stack tracking for each method call. Hence, method of biased locks. Given that ROLP installs an allocation con- call profiling code is only enabled for method calls that can text upon an object allocation, if the object becomes biased differentiate call paths leading to the same allocation site. locked, the profiling information will get overwritten. In This process is discussed in Section 5. addition, biased locking is controlled by the JVM using a spe- Finally, it is also possible to have collisions in the thread cific bit in an object header (bit number 3). Thus, if the object stack state, i.e., if two or more different call paths lead to the 4Biased Locking is a locking technique available for the HotSpot JVM which same execution stack state. This problem is greatly reduced allows locking an object towards a specific thread [17]. by two factors. First, we only profile hot code, thus greatly 4 Java ByteCode Jitted code for Invokevirtual
1. public Object mB() { public java.lang.Object mB(); 1. mov RX PTR(asmB+1) 2. Object o = mA(); Code: 2. mov RY [RX] 3. return o; 0: aload_0 3. test RY 4. } 1: invokevirtual #3 // Method mA:()Ljava/lang/Object; 4. je 6 4: astore_1 5. add [TLS + context_offset], RY 5: aload_1 6. call mA 6: areturn 7. test RY 8. je 10 9. sub [TLS + context_offset], RY
Figure 3. Method Call Code Sample: from Java (left) to Bytecode (middle) to x86 Assembly (right) reducing the number of method calls that can contribute to only the mov instruction in line 2 requires memory access a collision. Second, a collision would only be harmful if the (which is much slower compared to operations performed allocation site is the same for the values that are colliding. using only registers or cached values). However, even for Execution stack states that collide in different allocation sites this instruction, which is necessary to load into memory the are not a problem (i.e., they correspond to different lines in value that is added to the thread stack state, we try to keep the Object Lifetime Distribution table). Nevertheless, we it in cache by storing it right next to the compiled code in show in Section 8.3 that conflicts are very rare. memory. Thus, when the method’s Assembly code is loaded before it is executed, the value of asmB+1 will most likely be 3.2.4 Code Profiling Example cached in the CPU. We now analyze a snippet of code and see how ROLP installs 3.3 Updating the Object Lifetime Distribution Table the profiling code. Figure 3 presents a simple snippet ofJava code (left), the result of its compilation to Bytecode using the The information regarding the number of objects allocated Java compiler javac (center), and the x86 Assembly code for per allocation context and age, is kept in the global Object the invokevirtual instruction produced by the OpenJDK Lifetime Distribution table (see Fig. 1). Besides being updated HotSpot Opto JIT compiler (right), which also contains the upon object allocation (to increment the number of objects profiling code introduced by ROLP. Both the Bytecode and with age zero), this table is also updated during GC cycles the Assembly code presented in this figure are simplified to update the number of objects that survived a GC cycle. for clarity reasons. We do not present an example with the In particular, let’s assume an object allocated in the alloca- new instruction as it is more complex and would require tion context acm+i+t with age ageo that survives a GC cycle. more space to illustrate with almost no benefit compared to The Object Lifetime Distribution table will be updated to: analyzing the invokevirtual Assembly code. We now an- i) decrement the number in the cell corresponding to row alyze the Assembly code generated for the invokevirtual acm+i+t and column ageo (one object less with age ageo); ii) in- instruction (right side of Figure 3). crement the number in the cell corresponding to row acm+i+t Looking at the generated Assembly code, lines 1 to 5 and and column ageo+1 (one object more with age ageo+1). 7 to 9 correspond to profiling instructions introduced by This process is also depicted in Figure 1. In short, with ROLP(lines in bold). These instructions are meant to incre- ROLP, GC worker threads that are copying survivor objects ment (lines 1 to 5) and to decrement (lines 7 to 9) the thread will look into an object’s header (see Fig. 2) and extract the stack state by the specific amount that was calculated for this allocation context and the age of the object (field maintained specific line of codeas ( mB+1). The increment or decrement and updated by the collector). If the object is biased locked or Assembly instructions (add and sub) are executed on the if the allocation context is not present in the Object Lifetime condition that the value of asmB+1 is non-zero (note the test Distribution table, the object is not considered for profiling and je Assembly instructions in lines 3, 4, 7, and 8). purposes. Otherwise, the worker thread will update the table. This conditional execution of the thread stack state update, By the end of each GC cycle, the global table presented enables ROLP to turn on and off the profiling of method calls. in Figure 1 contains the number of objects organized by By doing so, ROLP avoids the execution of the add and sub allocation context and age. instructions which are costly as they may require loading and storing values to main memory (if the values are not 4 Inferring Object Lifetimes cached). In other words, ROLP introduces a not so expensive In order to infer the lifetime of objects allocated through short branch to avoid an expensive memory access. These a particular allocation context, e.g., acx, ROLP periodically instructions need to read and write to the current execution analyzes the number and age of the objects allocated through stack state which is stored context_offset bytes away from acx. This operation is performed for every allocation context the Thread Local Storage (TLS, which is kept in a special once every 16 GC cycles. This value is used because it is register). Other than these two instructions (add and sub), the maximum age of objects in HotSpot (considering that 5 Object Lifetime Distribution Estimated Object Number Allocation allocation site. With such a minimum set of method calls, Number Lifetime of Objects Allocation Context Age Table of Objects Context Conflict called S, it is sufficient to profile only the method calls inthe ...... set to solve all allocation context conflicts. In other words, acx
Figure 6. DaCapo Benchmark Execution Time Normalized to G1
Workload HS PMC PAS CF (# - %) avrora 32 MB 374 69 0 - 0.04 eclipse 1 GB 1378 329 0 - 1.20 fop 512 MB 3102 829 0 - 0.02 h2 1 GB 1416 116 0 - 1.80 jython 128 MB 11801 741 0 - 1.20 luindex 256 MB 464 89 0 - 0.60 lusearch 256 MB 558 127 0 - 1.80 pmd 256 MB 3157 369 6 - 1.20 sunflow 128 MB 346 225 0 - 1.00 tomcat 512 MB 2891 436 4 - 0.60 tradebeans 512 MB 2145 227 0 - 1.20 Figure 7. Worst-Case Conflict Resolution Time (ms) tradesoap 512 MB 5815 254 3 - 0.60 xalan 64 MB 2037 406 0 - 1.80 Table 2. DaCapo Profiling (left) and Conflicts (right) only from the profiling code inserted for allocation tracking. In other words, no profiling code in inserted for method calls; ii) fast-call-profiling represents the execution with all the profiling code enabled except thread stack state, i.e., benchmark with different levels of profiling to measure the no method call actually triggers the update of the thread impact of each type of profiling code in the benchmark’s stack state (as described in Section 3.2.4). In other words, all performance; and ii) simulate what would be the overhead method calls fall through the fast profiling branch, which of the conflict resolution algorithm (presented in Section 5) does not update the thread stack state; iii) real-profiling rep- and how long it would take in the worst-case scenario. resents real benchmark execution, with all the profiling code; Figure 6 presents the average execution time of each bench- iiii) slow-call-profiling represents the worst-case possible mark normalized to G1 (our baseline). Values above one execution, with all profiling code, forcing all method calls to means it took longer than G1 took to execute. For each update the thread stack state (as described in Section 3.2.4), benchmark, there are four columns (from left to right): i) i.e., all method calls fall through the slow profiling branch, no-call-profiling represents the execution time with no which updates the thread stack state. call profiling, i.e., only object allocation is profiled inthis We found the results in Figure 6 very interesting as differ- experiment and therefore, the execution overhead comes ent applications exercise the profiling code in different ways 10 resulting in different overheads for the same profiling code [11]); OLD, approximate memory overhead of the Object across different benchmarks. For example, for benchmarks Lifetime Distribution table (see Figure 1); such as fop, allocation profiling (the first bar from the left) From Table 1, three important points must be retained. leads to around 3% overhead while method call profiling Fist, looking at PAS and PMC, the percentage of profiled allo- leads to almost 10% overhead (difference between the first cation sites and method calls is small. This demonstrates that and second bars from the left). Other benchmarks reveal very the profiling effort is greatly reduced by only profiling hot different behavior, e.g., the sunflow benchmark, with high code locations, and by using optimizations such as avoiding overhead for allocation profiling and almost zero overhead inlined methods calls. Second, looking at OLD size, the mem- for method call profiling. It is also interesting to note that ory overhead introduced to support profiling information the real-profiling overhead is very close to the fast-call- does not exceed 16MB, a reasonable memory overhead con- profiling meaning that very few method calls were profiled sidering the performance advantages that can be achieved in order to solve allocation context conflicts. The left side of by leveraging the information in it. Finally, the number of Table 2 presents the memory budget (Heap Size) used to run allocation context conflicts does not exceed 3, showing that, each benchmark, number of profiled method calls (PMC), despite using a weak hash construction (based on addition the number of profiled allocation sites (PAS), and the num- and subtraction of hashes), it is possible to achieve a low ber of conflicts found while executing each benchmark. From number of conflicts. these results, we confirm that conflicts are not frequent. It is worthy to note that all the code changes done on On the right side of Table 2 we present the number of the applications, which are needed to use NG2C, require context conflicts and simulation results on the expected per- either human knowledge (i.e., the programmer), or the use centage of throughput overhead for having 20% of all method of ROLP. When using ROLP, such changes are done auto- calls being tracked (P from Section 5 is 20%). This throughput matically, i.e., the code is profiled and changes are done with overhead is directly proportional to P and thus, the higher no human intervention. ROLP additionally profiles other P is, the higher is the throughput overhead. P also impacts code locations (which are not used for NG2C), leading to the time to resolve conflicts. Figure 7 shows how long con- additional improvements. flict resolution would take in the worst-case scenario (we estimate this by taking the average time between two GC 8.4 Pause Time Percentiles and Distribution cycles) for different values of P. Figure 8 presents the results for application pauses across The low number of conflicts that most benchmarks evi- all workloads. Pauses are presented in milliseconds and are dence (right side of Table 2) suggests that thread stack state organized by percentiles. Note that these are pauses triggered tracking can be used to solve allocation context conflicts by GC only. Other pauses coming from I/O, OS syscalls, which, however, are rare. For P equals 20%, it is possible to among others, are not considered in this experiments so that observe that: i) conflict resolution overhead is never above we can concentrate our analysis on GC-induces pauses. In 1.8% of additional throughput overhead, and ii) conflict reso- the remaining text, we name the results obtained for NG2C lution can take up to 520 seconds but for most benchmarks with ROLP simply as ROLP. it does not take more than 2 minutes. It is still possible to Compared to G1 and CMS, ROLP significantly improves reduce the duration by increasing P to higher percentages. application pauses for all percentiles across all workloads. However, note that: i) ROLP is targeted to long running Regarding NG2C (which requires developer knowledge), applications and this setup time is negligible taking into con- ROLP approaches the numbers provided by NG2C in all sideration the overall runtime; ii) during the setup time, the workloads. From these results, the main conclusion to take is JVM is performing (w.r.t pause times) exactly like G1 (i.e., that ROLP can significantly reduce long tail latencies when with no profiling information, memory management resorts compared to G1 and CMS; in addition, it can also keep up to G1 with no modification). with NG2C, but without requiring any programming effort and knowledge. Both ROLP and NG2C produce very stable 8.3 Large-Scale Application Profiling pause times for most benchmarks, i.e., which do not increase significantly across percentiles, presenting a close to hori- This section summarizes the profiling used when evaluating zontal plotted line. Finally, reducing application pause time ROLP with the large-scale workloads, and also compares it does not mean reducing the GC throughput overhread (as to the amount of human-made code modifications necessary presented in the next section). This mostly comes from the for NG2C[11]. Table 1 presents a number of metrics for each fact that the total application pause time (i.e., sum of all ap- workload: PAS, percentage of allocation sites where profiling plication pauses) is very low when compared to the total code was actually inserted; PMC, percentage of method calls execution time of the application. where profiling code was actually inserted; CFs, number of So far, the presented application pause times were orga- allocation context conflicts; NG2C, number of code locations nized by percentiles. Figure 9 presents the number of appli- that were changed to evaluate NG2C (as previously reported cation pauses that occur in each pause time interval. Pauses 11 (a) Cassandra WI (b) Cassandra WR (c) Cassandra RI
(d) Lucene (e) GraphChi CC (f) GraphChi PR
Figure 8. Pause Time Percentiles (ms)
(a) Cassandra WI (b) Cassandra WR (c) Cassandra RI
(d) Lucene (e) GraphChi CC (f) GraphChi PR
Figure 9. Number of Application Pauses Per Duration Interval (ms) with shorter durations appear in intervals to the left while equivalent performance without requiring programmer ef- longer pauses appear in intervals to the right. In other words, fort and knowledge. the less pauses to the right, the better. ROLP presents signif- icant improvements regarding G1 and CMS, i.e., it results in 8.5 Warmup Pauses, Throughput, and Memory less application pauses in longer intervals, across all work- This section shows results on application warmup pause loads. When comparing ROLP with NG2C, both solutions times, throughput, and max memory usage. Note that ap- present very similar pause time distribution. plication warmup happens when its workload changes and In sum, ROLP allows NG2C to reduce application pauses ROLP is still detecting (i.e., learning) the lifetime of objects. by automatically pretenuring objects from allocation con- Clearly, such time interval should be the minimum possible. texts that tend to allocate objects with longer lifetimes. When Thus, the goal of this section is to show: i) how the learning compared to G1 and CMS, ROLP can greatly reduce applica- curve of ROLP affects pause times during warmup and how tion pauses and object copying within the heap. Once again, long does it take; ii) that ROLP does not inflict a significant we can say that when compared to NG2C, ROLP presents throughput overhead due to its profiling code; and iii) that ROLP does not negatively impact the max memory usage. 12 Figure 10. Cassandra WI Warmup Pause Times in ms (left) and Throughput (middle) and Max Mem. Usage norm. to G1 (right)
Figure 10, plot on the left, shows the Cassandra WI warmup for object lifetime profiling (both offline and online) andBig pause times for the first 600 seconds of the workload. Pause Data-friendly memory management techniques. times during the warmup phase can be divided into three parts. The first part spans from the beginning to around 250 9.1 Object Lifetime Profiling seconds. During this part of the execution, no information Hertz et al. [24] introduced an algorithm where an object is given to NG2C since ROLP is still gathering information lifetime is tracked based on timestamps which introduces a regarding objects’ lifetimes. Around second 250 (until sec- 300 times slowdown compared to a non-profiled run. Ricci et ond 350), ROLP already performed some lifetime estimations, al. [35] uses the same algorithm but adds new functionalities and NG2C starts pretenuring application objects resulting in in terms of precision and comprehensiveness (weak refer- reduced pause times. Finally, the third part of the warmup ences). Another system, Resurrector [40], relaxes precision starts around the second 350 when NG2C receives more in- to provide faster profiling but still introduces 3 to 40 times formation profiling information which is used to pretenure slowdown depending on the workload. more objects. In short, ROLP takes about 350 seconds to Blackburn et al. [6] extends the profile-based pretenuring stabilize the profiling information in Cassandra. In a real of Cheng’s solution [12] for Jikes RVM [1]. Blackburn et al. production environment, in which such workloads can run reports that it is particularly useful for tight heaps (at most for days, 350 seconds represents a very small time to stabilize 15 0MB) and not suitable for heaps with Gigabytes of objects. the system given its performance benefits. Harris [23] proposes a dynamic profiling technique whose With regards to throughput and max memory usage, Fig- objective is to decide, at allocation time, to either pretenure ure 10 (plots in the center and in the right) shows results the object being allocated or not. Compared to ROLP, this normalized to G1 (i.e., G1 results represent 1 for all columns). approach has one main limitation which is the fact that it ROLP presents a negligible throughput decrease, less than 5% targets heaps with only two generations. As shown in the (on average) for most workloads, compared to G1. Only for previous section, more generations are necessary to effec- GraphChi workloads, ROLP presents an average throughput tively split objects by estimated lifetime. overhead of 6% for both PR and CC). We consider this a neg- Sewe et al. [36] presents a headroom schema which drives ligible throughput overhead considering the great reduction pretenuring based on the space left on the heap before garbage in application long tail latencies. Memory usage also shows collection is necessary. Although their solution brings advan- a negligible overhead of ROLP compared to both G1 and tages to collection times, they push much of the overhead NG2C. Nevertheless, we are currently working on integrat- to the mutator and also to the off-line process, which is not ing previously proposed sampling techniques [27] to further always possible or accurate. Finally, Sewe et al.[36] do not reduce the throughput overhead introduced by ROLP. As target large heaps or a modern garbage collector like G1. discussed in Section 2.1, ZGC (concurrent collector) trades Compared to previous offline solutions, ROLP does not re- fully concurrent collection by extreme throughput overhead quire any source code modifications, no previous knowledge and higher memory usage. on the target workload, and it targets a widely employed industrial JVM. 9 Related Work However, in general, input influences the choices made Profiling plays a key role in managed runtimes, either for during memory management [31] motivating the need for code optimization or memory management decisions [1, 2, online profiling, which uncovers a number of new problems 23, 24, 35, 40, 41]. We focus on getting quality profiling in- such as context tracking. formation to drive object pretenuring. ROLP is, to the best Ball and Laurus [4] compute a unique number for each of our knowledge, the first online profiler targeting the dy- possible path of a control flow graph inside a procedure. The namic pretenuring of objects in Big Data applications run- computation is done offline and added to the source code. ning on HotSpot JVM, a highly optimized production JVM. This is not suited for ROLP because modern workloads have This section compares our work with state-of-art systems many possible paths inside each routine, and the technique 13 can not capture the inter-procedure path needed for ROLP to split into regions [38] explicitly created by the programmer distinguish allocation sites. Bond and McKinley [8] also com- (assumed to know which codebase creates related objects). pute a single value, but at runtime, to determine the sequence NG2C [11] extends G1 to support object pretenuring. How- of active stack frames in a inter-procedural way. However, ever, it also needs programmer’s help to identify the genera- they need to maintain non-commutativity to differentiate tion where a new object should be allocated. Cohen et al. [15] call sequences. This is not a requirement for ROLP and so extends the operation of the Immix garbage collector in Jikes we can have a smaller impact on code instrumentation. RVM [7] with a new programming interface between the NightWatch [22] is an allocation context-aware memory application and the GC, in order to manage dominant data allocator that tries to maximize cache locality. NightWatch structures (i.e. a data structure holding most of the objects and ROLP share the same idea of trying to capture the alloca- during the lifetime of the program) more efficiently. tion context for profiling purposes (to detect cache locality in the case of NightWatch, and to measure lifetime in the case 10 Discussion and Conclusions of ROLP). NightWatch is, however, optimized for large allo- This work proposed ROLP, a runtime object lifetime profiler cation chunks as it iterates through the call stack to generate which tells the collector where to allocate objects in order an allocation context. In the case of ROLP, which targets to minimize fragmentation. ROLP is implemented5 for the object oriented applications, iterating the call stack for every OpenJDK 8 HotSpot JVM and integrated with NG2C, a pre- object allocation is not feasible. Furthermore, runtimes (such tenuring collector based on G1 (the current default collector as the OpenJDK HotSpot JVM) tend to manage their own in HotSpot). Results show that ROLP can significantly reduce heaps, meaning that there will be few but very large alloca- pause times inflicted by the GC with very low throughput tion calls to the OS with the resulting memory being used to overhead. These results confirm the hypothesis that object contain objects with potentially very different lifetimes. lifetimes can be inferred from allocation contexts for Big Memento [14] gathers online feedback regarding object Data applications running on the JVM. lifetime by instrumenting allocation and installing mementos ROLP is provided as a launch time flag for the JVM and (allocation feedback) alongside objects. By using this infor- no user effort is required. ROLP also supports package-level mation Memento starts pretenuring objects from particular filters to either profile or not profile parts of the applica- allocation sites. Compared to ROLP, it has several drawbacks. tion code. These filters can be used to reduce the profiling First, it is only able to manage one tenured space, therefore overhead on large applications. Compared to the code anno- applying a binary decision that will still potentially co-locate tations required by NG2C, which requires programmers to objects with possibly very different lifetimes, incurring in guess the lifetime of objects and to understand the internals additional compaction effort. Second, Memento instruments of the JVM, these package filters are a simpler alternative, all application code while it is still being interpreted. This requiring close to no knowledge about the application. Nev- has two disadvantages compared to ROLP: i) all the appli- ertheless, it is possible to combine NG2C (hand-placed code cation code is being profiled, leading to a huge profiling annotations), POLM2 (offline profiling), and ROLP (online overhead (in ROLP, we only profile hot code locations); ii) profiling) as the three techniques use the same JVMand profiling stops when the code is JIT compiled, meaning that underlying collector. application behavior is only tracked while the application is ROLP can be easily ported to other runtimes. To do so, starting and the code is not jitted. Third, Memento does not however, we envision two main challenges: i) if the object track allocation contexts (i.e., call graph), which we found header is small (as it happens in many runtimes), profil- to be important to properly profile complex platforms such ing information might be stored elsewhere; ii) the collector as Cassandra. might have to be modified to support pretenuring as itis 9.2 Big Data-friendly Memory Management not a common feature in most collectors. Future work direc- tions include refining the profiling heuristics and continue We now describe systems that employ a less transparent research on low-overhead context hashing techniques. approach by requiring modifications to the heap organization and/or the collaboration of the programmer to instrument the code. Acknowledgments The work by Nguyen et al. [33, 34] reduces the number of This work was supported by national funds through Fun- objects in the heap by separating data from control paths and dação para a Ciência e a Tecnologia (FCT) with reference putting data objects in an off-heap structure. This technique UID/CEC/50021/2019 (INESC-ID), FCT scholarships SFRH/BD/ reduces the number of objects managed by the collector im- 103745/2014, SFRH/BSAB/135197/2017, and project PTDC/EEI- proving the application throughput and reducing latency. COM/30644/2017. However, the programmer is responsible for identifying and instrumenting the data path in the application code. A sim- ilar approach is followed by Broom [21] where the heap is 5The source code publicly is available at github.com/rodrigo-bruno/rolp. 14 References //doi.org/10.1145/2754169.2754181 [1] Matthew Arnold, Stephen Fink, David Grove, Michael Hind, and Pe- [15] Nachshon Cohen and Erez Petrank. 2015. Data Structure Aware ter F. Sweeney. 2000. Adaptive Optimization in the JalapeÑO JVM. In Garbage Collector. In Proceedings of the 2015 International Sympo- Proceedings of the 15th ACM SIGPLAN Conference on Object-oriented Pro- sium on Memory Management (ISMM ’15). ACM, New York, NY, USA, gramming, Systems, Languages, and Applications (OOPSLA ’00). ACM, 28–40. https://doi.org/10.1145/2754169.2754176 New York, NY, USA, 47–65. https://doi.org/10.1145/353171.353175 [16] David Detlefs, Christine Flood, Steve Heller, and Tony Printezis. 2004. [2] M. Arnold, S. J. Fink, D. Grove, M. Hind, and P. F. Sweeney. 2005. A Garbage-first Garbage Collection. In Proceedings of the 4th International Survey of Adaptive Optimization in Virtual Machines. Proc. IEEE 93, 2 Symposium on Memory Management (ISMM ’04). ACM, New York, NY, (Feb 2005), 449–466. USA, 37–48. https://doi.org/10.1145/1029873.1029879 [3] A. J. Awan, M. Brorsson, V. Vlassov, and E. Ayguade. 2015. Performance [17] D. Dice, M.S. Moir, and W.N. Scherer. 2010. Quickly reacquirable locks. Characterization of In-Memory Data Analytics on a Modern Cloud (Oct. 12 2010). https://www.google.ch/patents/US7814488 US Patent Server. In 2015 IEEE Fifth International Conference on Big Data and 7,814,488. Cloud Computing. 1–8. https://doi.org/10.1109/BDCloud.2015.37 [18] Christine H. Flood, Roman Kennke, Andrew Dinn, Andrew Haley, and [4] Thomas Ball and James R. Larus. 1996. Efficient Path Profiling. In Roland Westrelin. 2016. Shenandoah: An Open-source Concurrent Proceedings of the 29th Annual ACM/IEEE International Symposium on Compacting Garbage Collector for OpenJDK. In Proceedings of the 13th Microarchitecture (MICRO 29). IEEE Computer Society, Washington, International Conference on Principles and Practices of Programming on DC, USA, 46–57. http://dl.acm.org/citation.cfm?id=243846.243857 the Java Platform: Virtual Machines, Languages, and Tools (PPPJ ’16). [5] David A. Barrett and Benjamin G. Zorn. 1993. Using Lifetime Predictors ACM, New York, NY, USA, Article 13, 9 pages. https://doi.org/10.1145/ to Improve Memory Allocation Performance. In Proceedings of the 2972206.2972210 ACM SIGPLAN 1993 Conference on Programming Language Design [19] Lokesh Gidra, Gaël Thomas, Julien Sopena, and Marc Shapiro. 2012. and Implementation (PLDI ’93). ACM, New York, NY, USA, 187–196. Assessing the Scalability of Garbage Collectors on Many Cores. SIGOPS https://doi.org/10.1145/155090.155108 Oper. Syst. Rev. 45, 3 (Jan. 2012), 15–19. https://doi.org/10.1145/2094091. [6] Stephen M. Blackburn, Matthew Hertz, Kathryn S. Mckinley, J. Eliot B. 2094096 Moss, and Ting Yang. 2007. Profile-based Pretenuring. ACM Trans. [20] Lokesh Gidra, Gaël Thomas, Julien Sopena, and Marc Shapiro. 2013. Program. Lang. Syst. 29, 1, Article 2 (Jan. 2007). http://doi.acm.org/10. A Study of the Scalability of Stop-the-world Garbage Collectors on 1145/1180475.1180477 Multicores. In Proceedings of the Eighteenth International Conference [7] Stephen M. Blackburn and Kathryn S. McKinley. 2008. Immix: A Mark- on Architectural Support for Programming Languages and Operating region Garbage Collector with Space Efficiency, Fast Collection, and Systems (ASPLOS ’13). ACM, New York, NY, USA, 229–240. https: Mutator Performance. In Proceedings of the 29th ACM SIGPLAN Con- //doi.org/10.1145/2451116.2451142 ference on Programming Language Design and Implementation (PLDI [21] Ionel Gog, Jana Giceva, Malte Schwarzkopf, Kapil Vaswani, Dimitrios ’08). ACM, 22–32. http://doi.acm.org/10.1145/1375581.1375586 Vytiniotis, Ganesan Ramalingam, Manuel Costa, Derek G. Murray, [8] Michael D. Bond and Kathryn S. McKinley. 2007. Probabilistic Calling Steven Hand, and Michael Isard. 2015. Broom: Sweeping Out Garbage Context. In Proceedings of the 22Nd Annual ACM SIGPLAN Conference Collection from Big Data Systems. In 15th Workshop on Hot Topics on Object-oriented Programming Systems and Applications (OOPSLA ’07). in Operating Systems (HotOS XV). USENIX Association, Kartause It- ACM, New York, NY, USA, 97–112. https://doi.org/10.1145/1297027. tingen, Switzerland. https://www.usenix.org/conference/hotos15/ 1297035 workshop-program/presentation/gog [9] Rodrigo Bruno and Paulo Ferreira. 2017. POLM2: Automatic Profiling [22] Rentong Guo, Xiaofei Liao, Hai Jin, Jianhui Yue, and Guang Tan. 2015. for Object Lifetime-aware Memory Management for Hotspot Big Data NightWatch: Integrating Lightweight and Transparent Cache Pollution Applications. In Proceedings of the 18th ACM/IFIP/USENIX Middleware Control into Dynamic Memory Allocation Systems. In Proceedings of Conference (Middleware ’17). ACM, New York, NY, USA, 147–160. https: the 2015 USENIX Conference on Usenix Annual Technical Conference //doi.org/10.1145/3135974.3135986 (USENIX ATC ’15). USENIX Association, Berkeley, CA, USA, 307–318. [10] Rodrigo Bruno and Paulo Ferreira. 2018. A Study on Garbage Collection http://dl.acm.org/citation.cfm?id=2813767.2813790 Algorithms for Big Data Environments. ACM Comput. Surv. 51, 1, [23] Timothy L. Harris. 2000. Dynamic Adaptive Pre-tenuring. In Pro- Article 20 (Jan. 2018), 35 pages. https://doi.org/10.1145/3156818 ceedings of the 2nd International Symposium on Memory Management [11] Rodrigo Bruno, Luís Picciochi Oliveira, and Paulo Ferreira. 2017. (ISMM ’00). ACM, 127–136. http://doi.acm.org/10.1145/362422.362476 NG2C: Pretenuring Garbage Collection with Dynamic Generations for [24] Matthew Hertz, Stephen M. Blackburn, J. Eliot B. Moss, Kathryn S. HotSpot Big Data Applications. In Proceedings of the 2017 ACM SIG- McKinley, and Darko Stefanović. 2006. Generating Object Lifetime PLAN International Symposium on Memory Management (ISMM 2017). Traces with Merlin. ACM Trans. Program. Lang. Syst. 28, 3 (May 2006), ACM, New York, NY, USA, 2–13. https://doi.org/10.1145/3092255. 476–516. http://doi.acm.org/10.1145/1133651.1133654 3092272 [25] Richard Jones, Antony Hosking, and Eliot Moss. 2016. The garbage [12] Perry Cheng, Robert Harper, and Peter Lee. 1998. Generational Stack collection handbook: the art of automatic memory management. CRC Collection and Profile-driven Pretenuring. In Proceedings of the ACM Press. SIGPLAN 1998 Conference on Programming Language Design and Im- [26] Richard E. Jones and Chris Ryder. 2008. A Study of Java Object Demo- plementation (PLDI ’98). 162–173. http://doi.acm.org/10.1145/277650. graphics. In Proceedings of the 7th International Symposium on Mem- 277718 ory Management (ISMM ’08). ACM, New York, NY, USA, 121–130. [13] R. Clapp, M. Dimitrov, K. Kumar, V. Viswanathan, and T. Willhalm. https://doi.org/10.1145/1375634.1375652 2015. Quantifying the Performance Impact of Memory Latency and [27] Maria Jump, Stephen M. Blackburn, and Kathryn S. McKinley. 2004. Bandwidth for Big Data Workloads. In 2015 IEEE International Sympo- Dynamic Object Sampling for Pretenuring. In Proceedings of the 4th sium on Workload Characterization. 213–224. https://doi.org/10.1109/ International Symposium on Memory Management (ISMM ’04). ACM, IISWC.2015.32 New York, NY, USA, 152–162. https://doi.org/10.1145/1029873.1029892 [14] Daniel Clifford, Hannes Payer, Michael Stanton, and Ben L. Titzer. [28] Haewoon Kwak, Changhyun Lee, Hosung Park, and Sue Moon. 2010. 2015. Memento Mori: Dynamic Allocation-site-based Optimizations. What is Twitter, a Social Network or a News Media?. In Proceedings of In Proceedings of the 2015 International Symposium on Memory Man- the 19th International Conference on World Wide Web (WWW ’10). ACM, agement (ISMM ’15). ACM, New York, NY, USA, 105–117. https: New York, NY, USA, 591–600. https://doi.org/10.1145/1772690.1772751
15 [29] Aapo Kyrola, Guy Blelloch, and Carlos Guestrin. 2012. GraphChi: Large-scale Graph Computation on Just a PC. In Proceedings of the 10th USENIX Conference on Operating Systems Design and Implementation (OSDI’12). USENIX Association, Berkeley, CA, USA, 31–46. http: //dl.acm.org/citation.cfm?id=2387880.2387884 [30] Avinash Lakshman and Prashant Malik. 2010. Cassandra: A Decentral- ized Structured Storage System. SIGOPS Oper. Syst. Rev. 44, 2 (April 2010), 35–40. https://doi.org/10.1145/1773912.1773922 [31] Feng Mao, Eddy Z. Zhang, and Xipeng Shen. 2009. Influence of Program Inputs on the Selection of Garbage Collectors. In Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE ’09). ACM, 91–100. http://doi.acm.org/10.1145/ 1508293.1508307 [32] Michael McCandless, Erik Hatcher, and Otis Gospodnetic. 2010. Lucene in Action, Second Edition: Covers Apache Lucene 3.0. Manning Publica- tions Co., Greenwich, CT, USA. [33] Khanh Nguyen, Lu Fang, Guoqing Xu, Brian Demsky, Shan Lu, Sanazsa- dat Alamian, and Onur Mutlu. 2016. Yak: A High-performance Big- data-friendly Garbage Collector. In Proceedings of the 12th USENIX Conference on Operating Systems Design and Implementation (OSDI’16). USENIX Association, Berkeley, CA, USA, 349–365. http://dl.acm.org/ citation.cfm?id=3026877.3026905 [34] Khanh Nguyen, Kai Wang, Yingyi Bu, Lu Fang, Jianfei Hu, and Guo- qing Xu. 2015. FACADE: A Compiler and Runtime for (Almost) Object-Bounded Big Data Applications. In Proceedings of the Twen- tieth International Conference on Architectural Support for Program- ming Languages and Operating Systems (ASPLOS ’15). ACM, 675–690. http://doi.acm.org/10.1145/2694344.2694345 [35] Nathan P. Ricci, Samuel Z. Guyer, and J. Eliot B. Moss. 2011. Elephant Tracks: Generating Program Traces with Object Death Records. In Proceedings of the 9th International Conference on Principles and Practice of Programming in Java (PPPJ ’11). 139–142. http://doi.acm.org/10. 1145/2093157.2093178 [36] Andreas Sewe, Dingwen Yuan, Jan Sinschek, and Mira Mezini. 2010. Headroom-based Pretenuring: Dynamically Pretenuring Objects That Live "Long Enough". In Proceedings of the 8th International Conference on the Principles and Practice of Programming in Java (PPPJ ’10). ACM, 29–38. http://doi.acm.org/10.1145/1852761.1852767 [37] Gil Tene, Balaji Iyengar, and Michael Wolf. 2011. C4: The Continuously Concurrent Compacting Collector. In Proceedings of the International Symposium on Memory Management (ISMM ’11). ACM, New York, NY, USA, 79–88. https://doi.org/10.1145/1993478.1993491 [38] Mads Tofte and Jean-Pierre Talpin. 1997. Region-Based Memory Management. Inf. Comput. 132, 2 (Feb. 1997), 109–176. https: //doi.org/10.1006/inco.1996.2613 [39] David Ungar. 1984. Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm. In Proceedings of the First ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments (SDE 1). ACM, New York, NY, USA, 157–167. https://doi.org/10.1145/800020.808261 [40] Guoqing Xu. 2013. Resurrector: A Tunable Object Lifetime Profiling Technique for Optimizing Real-world Programs. In Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Pro- gramming Systems Languages & Applications (OOPSLA ’13). ACM, 111–130. http://doi.acm.org/10.1145/2509136.2509512 [41] Yudi Zheng, Lubomír Bulej, and Walter Binder. 2015. Accurate Profil- ing in the Presence of Dynamic Compilation. In Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Program- ming, Systems, Languages, and Applications (OOPSLA 2015). ACM, New York, NY, USA, 433–450. http://doi.acm.org/10.1145/2814270.2814281
16